Another very instructive video! Thank you very much for this clear presentation, for taking the time to popularize for the common man, I spend each time a wonderful moment, and I always look forward to the next video. Thank you very much for all this energy and involvement in the development of our favorite computer!
That was quite interesting. Thanks! I guess one of those critical warnings that Vivado reports during build was about the mismatch between the MAX10/max10 netlist reference in the block placement code ;-)
While floor planning like this can produce more consistent timing, you really should write the timing constraints to get consistent behaviour on things like the hyperbus. I've written a HyperRAM interface in about 200 cells for the Gowin GW1NR-9, where I did that timing by explicit instances of 4-bit SERDES IO blocks (one of which has an IODELAY on the clock), but without locking things in IOB hard function blocks what you need is relating the real world delays to the clocks. It's what SDC (synopsys design constraint) files are for. Once you have timing constraints in place the static timing analysis can report if it fails, and the timing driven place and route can try to get it right. The floor planning constraint reduces the temptation to do long paths, but doesn't tell the tool why they're wrong. HyperRAM can be a tricky beast. For one thing, the delay from clock to read data output isn't specified, but should ideally be measured at startup. That's probably part of why this HyperRAM controller is so large. Other parts might include totally redundant things like pipelined buffers. But the really significant part is if the IO registers aren't packed properly.
Thank you very much for the insight! I will definitely be reading up on this and discuss it with the team. I am still very much on apprentice level here and have much to learn :)
Another very instructive video! Thank you very much for this clear presentation, for taking the time to popularize for the common man, I spend each time a wonderful moment, and I always look forward to the next video. Thank you very much for all this energy and involvement in the development of our favorite computer!
Interesting, thanks for sharing!
Brilliant !
That was quite interesting. Thanks!
I guess one of those critical warnings that Vivado reports during build was about the mismatch between the MAX10/max10 netlist reference in the block placement code ;-)
They are only critical warnings... mostly IO pins connected to signals that don't exit anymore, so just a tedious cleanup job.
While floor planning like this can produce more consistent timing, you really should write the timing constraints to get consistent behaviour on things like the hyperbus. I've written a HyperRAM interface in about 200 cells for the Gowin GW1NR-9, where I did that timing by explicit instances of 4-bit SERDES IO blocks (one of which has an IODELAY on the clock), but without locking things in IOB hard function blocks what you need is relating the real world delays to the clocks. It's what SDC (synopsys design constraint) files are for. Once you have timing constraints in place the static timing analysis can report if it fails, and the timing driven place and route can try to get it right. The floor planning constraint reduces the temptation to do long paths, but doesn't tell the tool why they're wrong.
HyperRAM can be a tricky beast. For one thing, the delay from clock to read data output isn't specified, but should ideally be measured at startup. That's probably part of why this HyperRAM controller is so large. Other parts might include totally redundant things like pipelined buffers. But the really significant part is if the IO registers aren't packed properly.
Thank you very much for the insight! I will definitely be reading up on this and discuss it with the team. I am still very much on apprentice level here and have much to learn :)