Synthesis and FILE I/O?!

[Amal]

I often try to code as generic as possible so it can be reused across
multiple projects. When coding RAMs, ROMs or technology dependent
components, I pass a generic to select what target technology it is
going to be used. For ASIC, usually it is an instantiation of a hard
macro, and for FPGA I code so that the compiler can infer the proper
component.

For ROMs, the ASIC vendor ROM generator creates a text file that has
the contents of the ROM and the ROM model reads this file for
simulations. For FPGA I was forced to declare a constant array and
initialize it with the contents of the ROM. This way there is always
the danger or mismatch between the FPGA version and the ASIC version
of the ROM.

In VHDL and most languages, constants can be declared to call a
function that returns the proper constant value. If synthesis tools
allowed FILE I/O to be used in this context, then the same ROM file
that is generated by the ROM generator could be read in and passed to
the constant and the two implementations would be identical.

This would be a nice feature to have I think. I can think of other
scenarios that function calls and FILE I/O could be used in synthesis.
-- Amal

 

[Andy]

I agree. Once upon a time, I needed to translate a PAL into an FPGA,
and had a vhdl simulation model that would read the fusemap (jedec)
file, and that drove generate statements to create the AND-OR tree.
Since it was all done pre-elaboration, it should be able to work, but
the synthesis tools just threw up their hands and said "We don't
support text io!". Of course, not many synthesizers have separate
analysis and elaboration phases, so maybe there's part of the
problem.

As a work around, if you had a script written in perl, etc. to
translate the memory file into a vhdl package file that declared a
constant with the file's contents, that could work too.

Andy

 

[David R Brooks]

I agree. Once upon a time, I needed to translate a PAL into an FPGA,
and had a vhdl simulation model that would read the fusemap (jedec)
file, and that drove generate statements to create the AND-OR tree.
Since it was all done pre-elaboration, it should be able to work, but
the synthesis tools just threw up their hands and said "We don't
support text io!". Of course, not many synthesizers have separate
analysis and elaboration phases, so maybe there's part of the
problem.

As a work around, if you had a script written in perl, etc. to
translate the memory file into a vhdl package file that declared a
constant with the file's contents, that could work too.

Andy

I think the latest Xilinx tools can do something of this kind, but of
course, you're not vendor independent (is that an issue for you?)
If vendor-independence is required, then a separate (Perl?) script is
probably the way to go.

 

[Amal]

I think the latest Xilinx tools can do something of this kind, but of
course, you're not vendor independent (is that an issue for you?)
If vendor-independence is required, then a separate (Perl?) script is
probably the way to go.

A vendor independent solution would be good, although it is hard to
convince vendors to implement a synthesis subset of the language that
there is no hard standard for it.

-- Amal

 

[Jim Lewis]

Amal,

A vendor independent solution would be good, although it is hard to
convince vendors to implement a synthesis subset of the language that
there is no hard standard for it.

So revive 1076.6 working group, get vendors involved, and
update the standard. If you need help, I can advise in the
process.

Cheers,
Jim Lewis

 

[Brian Drummond]

For ROMs, the ASIC vendor ROM generator creates a text file that has
the contents of the ROM and the ROM model reads this file for
simulations. For FPGA I was forced to declare a constant array and
initialize it with the contents of the ROM. This way there is always
the danger or mismatch between the FPGA version and the ASIC version
of the ROM.

In VHDL and most languages, constants can be declared to call a
function that returns the proper constant value. If synthesis tools
allowed FILE I/O to be used in this context, then the same ROM file
that is generated by the ROM generator could be read in and passed to
the constant and the two implementations would be identical.

In the absence of synthesisable FILE I/O, your ROM model can use the
"synthesis off" pragmas enclosing a file reader - not to initialise the
constant array from the file - but to ASSERT that the constant array is
identical to the file, with severity FATAL.

You still have duplication, but at least you will catch and eliminate
any mismatch between copies before reaching synthesis.

- Brian