XST: suppressing incorrect optimizations in VHDL code

Marc Randolph <mrand@my-deja.com> wrote in message news:<vf-dnWXXTflpvxvcRVn-vg@comcast.com>...

> I still must be missing something... I don't see how pushing the pin 
> location assignments deep into the hierarchy makes anything easier. 

It enhances the maintainability of the code, by concentrating all the
knowledge about the particular hardware devices available in one
place. For example, adding support for yet another board is then a
matter of making one "mmapped_io_<boardtype>.vhdl" and recompiling.

> You  can always make the bus wider need it needs to be to the top level - the 
> tools will optimized it down to the correct width.

This is one of many options to work around the problem.

> >>Even if you don't use a port, don't you still need different top level files?
> > I don't see why that would be necessary.
> 
> Unless it is necessary because some tools require it.  :-)   I don't 
> pretend to know if VHDL requires the ports to be at the top level or 
> not, but it would not surprise me if some of the tools don't handle it 
> correctly.

That's very true. The fact that XST seems to handle non-toplevel
outgoing signals fine but isn't able to recognize incoming signals as
drivers suggests the possibility that it is just a problem in XST.

Cheers,
  Sidney

sidney@jigsaw.nl (Sidney Cadot) wrote in message 

<snip>
> 
> All I am asking is for a way to coerce XST to handle input signals in
> a similar way.
> 
> Regards, Sidney
<snip>

As others have already mentioned, one can use generic and conditional
generate statements to customize the designs.

I'm not aware that standard VHDL has a preprocessor #ifdef mechanism. 
There appear to be some third party offerings.  One may easily write
one that does the job with sed (less than 10 lines).

The method that you are pursuing may not work in future version of the
tools, but that is really for you to decide.  A possible solution to
get around the dilemma you face is to use an IOBUF instead of an IBUF,
and strap the T pin so the output is always tristated.  I personnally
do not recommend going this route, but it is really your call.

Newman

Hi Chris,

> This isn't the perfect solution, but in verilog you could do something
> like use a define to set the board type and then a bunch of ifdef's to
> monkey with the port lists on the higher level modules.  You could
> even use an ifdef to instantiate the correct hardware specific
> low-level module.  If you don't want to contaminate the top-level
> files, you can include the portions that are different out of other
> files.  Basically, the idea is to use the pre-processor rather than
> the HDL's abstraction model to hide the hardware details.  I'm sure
> there's a similar mechanism in VHDL?

I'm afraid there is no mechanism analogous to textual preprocessing
like we have in C for VHDL. Nothing is keeping me from using a
preprocessor despite that, of course, but life would be just so much
easier if I can solve this at the VHDL level.

> Okay, it's not perfect, but it works for C programmers writing
> multi-platform code...   (What's really cool is if you run the whole
> thing with a makefile, you can pass the matching parameters not only
> to the hdl complier, but also to the compiler of the software that
> runs on your SoC)

Well I do tie everything together using a Makefile, I could easily
insert a preprocessing stage ... but this would make my stuff
considerably less easy to re-use for other people (I intend to publish
the project on the Web).

> PS - these spartan 3 kits are fun... with the addition of one chip and
> a bunch of resistors,

Yes, it is great stuff. I implemented a 6502 from scratch, which uses
the internal block memory of the Spartan-III .... I implemented a very
small machine language monitor program that works via the RS232, and I
must say it's really something to type to this little computer and get
a response that shows it works - also happy to be able to rehash those
old 8-bit skills I picked up 20 years ago :-) I can also run C
programs on this thing (using CC65, www.cc65.org) which is perfect.
It's been a very educational project so far, I've had several
occasions to think "so _that_'s why they do it like that!" :)

The digilent/xilinx kit is quite fantastic and really a bargain, at a
hundred bucks including the JTAG cable and power supply. I was
especially happy with the quality of hardware documentation they
provide, after horrific experience in this respect with my NuHorizons
kit. The Memec kit I have is also nice by the way, I also have their
50 MHz AD converter kit I use for experiments. Great stuff.

> I have one of the digilent ones pulling pictures
> off an IDE hard drive and generating a color composite NTSC signal to
> drive a little LCD tv...

Sounds great! I have been thinking about implementing an IDE interface
myself, do you have any more info, e.g. did you implement the IDE core
yourself?

Regards, Sidney

sidney@jigsaw.nl (Sidney Cadot) wrote in message news:<741e0fbf.0411010028.3ea1a7f3@posting.google.com>...
> newman5382@aol.com (newman) wrote in message news:
> 
> The "external view" (VHDL wise) of my "mmapped_io" component is
> basically that it acts like a RAM block, i.e., it has a data bus and
> an address bus, and R/W control bits. The fact that these happen to do
> some interesting things to hardware, should be of no concern to the
> VHDL modules that instantiate an "mmapped_io" component, that's the
> whole point of having memory mapped I/O.

As I think about this more, it looks to me like you're not really
architecting this in a way consistent with the philosophy of a
hardware description language.  Remember, this is sort of a software
equivelent to putting chips on boards and wiring them together.  So
unless one of your chips happens to be something "magic" like a
self-contained RF module, nothing gets into or out of a chip unless
you provide traces on the board to get it there.  Software engineers
get pure abstaction; hardware engineers just get 3ghz wire wrap guns.

From that point of view, I think you should think of your universal
bits of code as modules with no real-world I/O - for example, your
CPU, any on-chip memory, any other internal functional blocks.  Build
those into a library of general purpose functions that  you can use in
any of your projects.

Then for each specific FPGA board, create a top-level module with the
actual physical I/O ports.  This module should then instantiate a mix
of both your library of internal functional modules like CPU, and
hardware-specific handler modules for the specific board like your
memory mapped io function.  You will of course have to wire the
physical I/O ports through to those modules which need them, possibly
leaving any extrnal tri-states in the top level and passing something
back up to control them.

And of course if you do system simulation, you would in turn treat the
formerly top-level module as just one component in a testbench module
where it gets wired up to simulations of whatever your board talks
to...

Chris

Sidney,
> I failed to make that particularly clear (sorry). There are hardware
> differences, e.g.
> 
> * The number of seven-segment displays 0/1/4
> * The number of LEDs 4/8/8
> * The number of push-buttons: 2/3/4
> * The number of sliding switches: 0/4/8
> * The availability of AD/DA's on the development board
> * The interface to memory residing on the memory board

I have noticed that XST will remove pins at the top level of
a design that are not connected.  Hence, you could create a
design with the maximum number of pins you need at the top
level and then control whether the functionality is in the
design or not with generate.  Control the generate with
constants from a package.  Have one package for each board
configuration.  I am not sure what other synthesis tools do
with IOs so this may not work for all synthesis tools.

If you have excess IO, you can be even lazier.  Skip the
generate statements, implement all of the functionality
in the device, but allow unused functionality connect to
unused device pins.  This works well for outputs, but for
inputs, your design may have to be configured to ignore
the unused ones.  I use this to make some of our lab projects
work on different FPGA boards (Xilinx and Actel for now).

VHDL does not have any conditional statements outside of
generate, however, it would be simple enough to use CPP
as a preprocessor and script your compiles to always use
CPP - of course that would mean that everyone that uses
the files would have to do this also.  I have done some
experiments with this and it seems to work easy enough.

Cheers,
Jim
-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jim Lewis
Director of Training             mailto:Jim@SynthWorks.com
SynthWorks Design Inc.           http://www.SynthWorks.com
1-503-590-4787

Expert VHDL Training for Hardware Design and Verification
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

>I'm not aware that standard VHDL has a preprocessor #ifdef mechanism. 
>There appear to be some third party offerings.  One may easily write
>one that does the job with sed (less than 10 lines).

Standard cpp works fine.  Everything gets much saner if you have a makefile.

-- 
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

sidney@jigsaw.nl (Sidney Cadot) wrote in message news:<741e0fbf.0411011110.1fcf2e1b@posting.google.com>...
> Marc Randolph <mrand@my-deja.com> wrote in message news:<vf-dnWXXTflpvxvcRVn-vg@comcast.com>...
> 
> > I still must be missing something... I don't see how pushing the pin 
> > location assignments deep into the hierarchy makes anything easier. 
> 
> It enhances the maintainability of the code, by concentrating all the
> knowledge about the particular hardware devices available in one
> place. For example, adding support for yet another board is then a
> matter of making one "mmapped_io_<boardtype>.vhdl" and recompiling.

But you may not even need different vhdl files if you use your .ucf
file (or whatever it is called in XST) to call out pin numbers.

Have fun,

   Marc

hmurray@suespammers.org (Hal Murray) wrote in message news:<cNmdnRwJMaA2TBvcRVn-uA@megapath.net>...
> >I'm not aware that standard VHDL has a preprocessor #ifdef mechanism. 
> >There appear to be some third party offerings.  One may easily write
> >one that does the job with sed (less than 10 lines).
> 
> Standard cpp works fine.  Everything gets much saner if you have a makefile.

Hal,
  Thanks for the tip.  I'll have to try it out sometime.  My sed trick
worked OK for small design differences, but it raised a few
eye-browses because it was so ad-hoc.

Newman