<emeb_mac>
I've designed so many DSP pipelines that this kind of stuff is 2nd nature, but that doesn't mean it can't have rough spots.
<emeb_mac>
Just wrapped up HDL design work on a big OFDM receiver - there were some "fun" bits in that. A frequency domain equalizer with all kinds of memory and feedback that took me nearly a month to get working...
<awygle>
dang, that's impressive. ofdm is scary
<ZipCPU>
... Still working on my FFT here ...
<emeb_mac>
Oh fun!
<ZipCPU>
Once the FFT is done, the rest of any OFDM design should be fairly easy in comparison.
<ZipCPU>
;)
<emeb_mac>
We just plopped down IP cores from the FPGA vendor.
<awygle>
i did a DSSS receiver once and the hardest part was locking to the code
<ZipCPU>
awygle: Yep! Now, knowing what I do, I could probably do a DSSS receiver a lot cheaper than the last one I did ...
<emeb_mac>
Not really much point in putting effort into the FFT when the vendor core is free and well optimized & debugged.
<awygle>
ZipCPU: if i ever get back into the satellite radio market, i'll give you a call ;)
<ZipCPU>
:)
<ZipCPU>
emeb_mac: To each their own calling.
<awygle>
i have like 75% of a design for a quarter-watt couple-MHz SDR board for cubesats
<emeb_mac>
ZipCPU: if you're having fun :)
<awygle>
but my business fell apart before i had reason to pull the trigger on it
<emeb_mac>
ZipCPU: and FWIW - there's a lot more to a successful OFDM system than just the FFT.
<ZipCPU>
emeb_mac: There's more to it than just that. I keep seeing students trying to figure out why the proprietary vendor design isn't doing what they are expecting. A nice clear open source design would therefore be valuable for understanding what's going on under the hood.
<ZipCPU>
emeb_mac: Well said, well said.
<emeb_mac>
and yeah - having access to source is a good thing
<emeb_mac>
On a previous project we had the option of building or buying an LDPC decoder and decided to build it in house.
<ZipCPU>
I mean .... even if the design component works, sometimes it helps to trace through it to understand why your wrapper isn't working.
<emeb_mac>
It was hard but we learned a lot.
<ZipCPU>
Oooohh ... LDPC, that's a fun one.
<emeb_mac>
Yeah
<awygle>
LDPC is super cool
<awygle>
another good satellite tech
<emeb_mac>
It took a while but actually was cheaper than buying.
<ZipCPU>
The last FEC decoder I built in Verilog was a product code, quite a fun challenge.
<emeb_mac>
because the folks selling them want arm + leg.
<ZipCPU>
Well, if it works, it might just be worth both arms and legs ... just to spare you the hassle of finding the bugs in your own.
<emeb_mac>
OTOH, for this project we needed a rate 1/2 Viterbi decoder and didn't want to waste effort on that so we just bought the Xilinx core.
<sorear>
It would be nice if you could assume commercial IP was bug-free
<ZipCPU>
Heheh ... I remember building a 1/2 rate Viterbi decoder--wasn't in Verilog though. C++ instead.
<ZipCPU>
sorear: Don't steal my innocence, please. :D
<emeb_mac>
There's a lot of open source code for that stuff.
<emeb_mac>
We had a project that needed a BCH decoder and found one written in Verilog.
<emeb_mac>
Converted it to our own favorite VHDL and it worked fine.
<awygle>
i wrote a BCH encoder in C recently
<awygle>
it really annoys me when FEC people don't pubish test vectors
<emeb_mac>
heh
<ZipCPU>
Aw, come on ... it's just a linear system.
<awygle>
like "i'm TRYING to be compatible to your stupid standard, throw me a bone here!"
<ZipCPU>
Pick your favorite basis set and go. That should be sufficient.
<awygle>
CRCs are the worst this way, historically lol
<ZipCPU>
Yeah, okay, I'll grant you CRC's. There are just too many implementations of them. Do they start with the zero state or the ones state, do you xor the result with zeros or ones when done, which way do the bits go in, etc.
<emeb_mac>
I know Russ from elsewhere on IRC and actually sent him some bugfixes we found while using his stuff.
<ZipCPU>
I've wanted to blog about how formal can help doing CRC's for ethernet, but ... haven't gotten that far. Really makes building them easy.
<emeb_mac>
I'll bet
<emeb_mac>
CRCs are interesting - we're using some in the OFDM project
<ZipCPU>
Heh ... it's even easier when you control the whole link.
<emeb_mac>
yes, very.
<emeb_mac>
match up the tx & rx. done.
<emeb_mac>
but then we model *everything* in Matlab before starting to code HDL
<emeb_mac>
so we know what's going to happen up front.
<ZipCPU>
Well, why not? It's often faster and easier to do so.
<emeb_mac>
yes
<ZipCPU>
What I don't get are the newbies that try to build something really complex without first understanding the technology.
<emeb_mac>
and since we don't grok formal, all our testing is vector-based with references from the Matlab sim
<ZipCPU>
They then get confused as to why it doesn't work. You ask about their pre RTL simulation, and just get blank looks.
<emeb_mac>
yes - we see that too
<emeb_mac>
lol
<ZipCPU>
Formally verifying an FIR filter was a fun challenge. Not your typical formal proof.
<emeb_mac>
so many of our customers just start out throwing HDL at the wall
<emeb_mac>
no verification process at all
<emeb_mac>
"we can debug on the bench - FPGAs make it easy!"
<ZipCPU>
Lol!
<emeb_mac>
When an edit/compile/test cycle takes 2 hours, you can't get much debugging done in a workday.
<emeb_mac>
I use Matlab to generate stimulus / response (with fixed-point implementation code) for the entire datapath.
<emeb_mac>
then we unit test each step in the path and end-to-end after integration
<ZipCPU>
Yeah ... but you can do a *lot* of blogging during that time!
<emeb_mac>
haha
<emeb_mac>
or watch cat videos!
<ZipCPU>
Been there, done that, blogging increases my code quality, cat videos don't.
<awygle>
or play fetch with the cat
<ZipCPU>
Fooseball anyone?
<awygle>
cat doesn't know how to play that yet
<ZipCPU>
The other fun alternative here is to distract the security officer.
<emeb_mac>
heh - work from home. no security officer.
<ZipCPU>
She's works for a "Shepherd Security Services" firm. It's a German company.
<emeb_mac>
lol
<emeb_mac>
Tacos al pastor Aleman
digshadow has quit [Ping timeout: 276 seconds]
seldridge0 has joined #yosys
digshadow has joined #yosys
digshadow has quit [Ping timeout: 260 seconds]
develonepi3 has quit [Remote host closed the connection]
<dmin7>
seems like i am addressing the triggers (2d) array wrong
<dmin7>
(the for loop is just for some debugging data)
<dmin7>
ctrl_addr[3:0] should contain an id from 0-15
<dmin7>
and i have to split the bus read/write into two times 32bit .. but that works fine for the counter, so that shouldn't be the problem
<ZipCPU>
Most block RAM's cannot be initialized on reset.
<ZipCPU>
$readmemh usually works much better.
X-Scale has joined #yosys
cemerick has joined #yosys
cemerick_ has quit [Ping timeout: 252 seconds]
<ZipCPU>
Likewise, many design tools cannot recognize block RAM's buried deep into the logic of a process. They require reads to be as simple as either an assignment or a, always @(posedge i_clk) trigger_data <= triggers[ctrl_addr[3:0];
<ZipCPU>
Sometimes you can do your selection on the next clock, "assign ctrl_rdat = (ctrl_state == 0) ? trigger_data[63:32] : trigger_data[31:0];
seldridge0 has joined #yosys
cr1901_modern has quit [Ping timeout: 260 seconds]
cr1901_modern has joined #yosys
develonepi3 has quit [Remote host closed the connection]
develonepi3 has joined #yosys
cemerick_ has joined #yosys
cemerick has quit [Ping timeout: 252 seconds]
GuzTech has quit [Quit: Leaving]
FabM has quit [Quit: ChatZilla 0.9.93 [Firefox 52.7.3/20180326230345]]
emeb has joined #yosys
cr1901_modern has quit [Ping timeout: 245 seconds]
leviathan has joined #yosys
leviathan has quit [Client Quit]
leviathan has joined #yosys
cr1901_modern has joined #yosys
Aditya has joined #yosys
<shapr>
y0 y0 y0 sys!
Aditya has quit [Quit: Leaving]
seldridge0 has quit [Ping timeout: 240 seconds]
mazzoo_ has quit [Ping timeout: 245 seconds]
mazzoo has joined #yosys
<dmin7>
ZipCPU: thanks for the hint. (the problem was the memory addresses / index's i tried to use; 0-15 instead of multiples of 4)
mazzoo has quit [Ping timeout: 252 seconds]
mazzoo has joined #yosys
digshadow has quit [Ping timeout: 245 seconds]
develonepi3 has quit [Remote host closed the connection]
<azzizi>
So write_verilog transfers the intermediate RTLIL information of a source code to synthesizing according to the platform intended. But suppose I wanted to see the RTLIL step for the code, capture it and edit some of it and then synthesize it, would it be possible with this tool?
<azzizi>
I suppose I can see the RTLIL of any code with the dump_rtlil but can I make any changes to the generated RTLIL before the synthesize step?
<azzizi>
Also, which intermediate format: ast1 or ast2 or ILANG or RTLIL is the strongest i.e. doesn't lose any information? With that I mean all the source code indormation is there in that format?
<azzizi>
And suppose I have a behavioral source code form where I get the platform-specific Verilog code using the write_verilog; my question is can I get back to the original behavioral code from the platform-specific Verilog code?