[HN Gopher] A Hack to Update RAM Initialization Contents in Inte...
___________________________________________________________________
A Hack to Update RAM Initialization Contents in Intel FPGA
Bitstreams
Author : parsecs
Score : 58 points
Date : 2021-04-26 14:11 UTC (8 hours ago)
(HTM) web link (tomverbeure.github.io)
(TXT) w3m dump (tomverbeure.github.io)
| evancox100 wrote:
| Good article, but please don't use defparam!
| tverbeure wrote:
| This was just a cut-and-paste from an Intel example.
|
| But any strong reason why? Do you prefer specifying the params
| as part of the module instantiation itself?
| evancox100 wrote:
| Yes, use the #(...) syntax. This has been around since
| Verilog 2001 and is universally supported. defparam has been
| deprecated and "might be removed from future versions of the
| language" (section 23.10.1 of SystemVerilog 2017 spec). They
| would never actually do this since breaking backwards
| compatibility is anathema to the industry, but it's not the
| best thing to use if you can avoid it.
|
| One of the main problems with defparam is that you can
| redefine anything anywhere. The SystemVerilog spec (weirdly)
| touts this as a benefit: "The defparam statement is
| particularly useful for grouping all of the parameter value
| override assignments in one module". Then gives an example
| that would strike fear into the heart of both verification
| AND design engineer, where a lone "annotate" module with just
| defparams redefines the parameters at multiple levels of a
| completely unrelated hierarchy of other modules.
|
| In reality chip designs are so much larger these days that it
| would be information overload to try to define ever parameter
| in a single module that you would have to update any time the
| hierarchy anywhere in your chip changed. It is just such a
| nonstarter, it's kind of astounding that statement is still
| in there. It probably dates back to the introduction of the
| feature.
| snvzz wrote:
| It's helpful if you got one of these.
|
| But even better is to get a FPGA supported by the open stack, and
| not have to deal with any of this.
|
| iCE40 and ECP5 have been pure joy to me.
| tverbeure wrote:
| I have a very nice stable of ICE40 and ECP5 FPGA boards, but I
| always go back to Intel FPGAs for development. And when I'm
| done, I may port it to an open source supported FPGA.
|
| Because the synthesis QoR and features of Quartus (don't
| confuse it with the Quartus GUI) is miles ahead of Yosys and
| NextPnR.
|
| And, most important, the ease of use and features of Signaltap.
| The open source equivalents for that don't come close.
| aseipp wrote:
| I mean, most of the blog post is actually in some sense
| relevant regardless, because updating blockram contents and
| blockram inference is relevant to all the tools. And in some
| cases the problem is actually worse in the open source tools,
| e.g. ECP5 blockram inference is very incomplete in Yosys,
| meaning you have to manually instantiate the primitive anyway
| for reliability. So actually you have to deal with "any of
| this" quite a lot more in open source tooling in some cases.
|
| I'm also not sure what the point of posts like this in general
| are. "You've done this thing. But I don't like it. Why didn't
| you do this other thing instead, that I like and confirms my
| priors?" Well, because they presumably had this particular
| problem, not whatever problem you would prefer them to have. It
| would be nice, though.
| [deleted]
___________________________________________________________________
(page generated 2021-04-26 23:01 UTC)