Synthesis and FILE I/O?!

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

Amal

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

On Apr 3, 10:30 am, "Amal" <akhailt...@gmail.com> wrote:
> 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

Andy wrote:
> 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
>
> On Apr 3, 10:30 am, "Amal" <akhailt...@gmail.com> wrote:
>> 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
>
>
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.

David R Brooks

On Apr 3, 3:30 pm, David R Brooks <daveb...@iinet.net.au> wrote:
> Andy wrote:
> > 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
>
> > On Apr 3, 10:30 am, "Amal" <akhailt...@gmail.com> wrote:
> >> 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
>
> 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

Amal

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

Jim Lewis

On 3 Apr 2007 08:30:16 -0700, "Amal" <> wrote:


>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

Brian Drummond