Synthesis for 22v10

Discussion in 'VHDL' started by a, Aug 15, 2006.

  1. a

    a Guest

    Howdy all -

    I'm an ECE grad student and I'd like to come up to speed on
    VHDL/Verilog. There are classes on this (and I'll be
    taking some) but apparently the emphasis is solely on simulation.
    I've asked profs about synthesis and generating JEDEC files
    and got some rather vague suggestions about downloading from
    Altera or Xilinx.

    At any rate, I have a programmer that can do smaller DIP parts and
    picked up some 22CV10 PEEL devices and would like to generate a
    JEDEC fuse file for them. Sure, they're small parts and all, and
    VHDL/Verilog is overkill for them, but I'm learning and why not?
    I see no reason not to use an HDL for decoders and so forth.

    So I did download Quartus II from Altera and fussed with the licensing,
    etc., but it doesn't seem to support older devices. I couldn't get
    the Xilinx stuff to run.

    So, should I download the legacy product? Can anybody tell me if
    MAX+PLUS II (interesting name, is it "max plus plus"? or maybe
    "max and plus"?) supports smaller devices?

    Any other options? I did a search of Google groups but didn't turn
    up anything. I've also tried gEDA on Linux but neither of the last two
    releases would even install on a RH9 platform.

    Thanks,

    Rick

    rc |a| ece.pdx.edu
     
    a, Aug 15, 2006
    #1
    1. Advertising

  2. a wrote:

    > I'm an ECE grad student and I'd like to come up to speed on
    > VHDL/Verilog. There are classes on this (and I'll be
    > taking some) but apparently the emphasis is solely on simulation.
    > I've asked profs about synthesis and generating JEDEC files
    > and got some rather vague suggestions about downloading from
    > Altera or Xilinx.


    Until you know how to write hdl code for synthesis
    *and* verify it with simulation, device selection
    is premature.

    -- Mike Treseler
     
    Mike Treseler, Aug 15, 2006
    #2
    1. Advertising

  3. a

    David Ashley Guest

    a wrote:
    >
    > Howdy all -
    >
    > I'm an ECE grad student and I'd like to come up to speed on
    > VHDL/Verilog. There are classes on this (and I'll be
    > taking some) but apparently the emphasis is solely on simulation.
    > I've asked profs about synthesis and generating JEDEC files
    > and got some rather vague suggestions about downloading from
    > Altera or Xilinx.
    >
    > At any rate, I have a programmer that can do smaller DIP parts and
    > picked up some 22CV10 PEEL devices and would like to generate a
    > JEDEC fuse file for them. Sure, they're small parts and all, and
    > VHDL/Verilog is overkill for them, but I'm learning and why not?
    > I see no reason not to use an HDL for decoders and so forth.
    >
    > So I did download Quartus II from Altera and fussed with the licensing,
    > etc., but it doesn't seem to support older devices. I couldn't get
    > the Xilinx stuff to run.
    >
    > So, should I download the legacy product? Can anybody tell me if
    > MAX+PLUS II (interesting name, is it "max plus plus"? or maybe
    > "max and plus"?) supports smaller devices?
    >
    > Any other options? I did a search of Google groups but didn't turn
    > up anything. I've also tried gEDA on Linux but neither of the last two
    > releases would even install on a RH9 platform.
    >
    > Thanks,
    >
    > Rick
    >
    > rc |a| ece.pdx.edu


    a,

    I don't know what the 22CV10 is. The numbers reminded me of the GAL22V10,
    is it a GAL? I spent a few minutes searching but just found pay for access
    datasheets, and gave up.

    At any rate I'm in a similiar situation. I'm trying to gain some familiarity
    with VHDL and FPGA's. I happened upon GHDL, and it has been useful
    somewhat. The combination of GHDL to simulate VHDL and GTKWave to
    view the results has been ok so far, and it seems to be fast enough.

    I purchased from Xilinx a Spartan-3E starter kit, it has lots of interesting
    parts on it. I wrote VHDL code and used the Xilinx tools (ISE, 8.1i) to
    synthesize bit files for the Spartan XC3S500E on the board. I got stable
    SVGA video out of the connector, with a pattern of random colors on
    the background, and as an exercise a black square bouncing around the
    display.

    Each iteration of change source -> build bitfile -> try it out on actual
    hardware was getting longer and longer as the design was getting more
    complicated. It was a single VHDL file about 100 lines or so. And it
    was taking a few minutes to build within the Xilinx tools.

    I had no debugging capability at all -- can't see what signals are doing.
    Not the best way to debug.

    So I moved to GHDL + GTKWave.

    I want to develop under linux. I find I could get the ISE + Xilinx tools to
    install under linux. The USB driver I couldn't get working 100% from
    linux. It uses a mechanism where when the USB is first plugged into
    the computer, the driver downloads new code to the USB device, and that
    then does the required jtag interface + whatnot. This works from
    windows 2000 + windows versions of xilinx tools, not from linux.

    However if I first boot into windows, plug the USB cable in on the
    spartan-3e starter board, then let it initialize, I can reboot into linux
    and linux will be able to download over the jtag/usb from then on
    until I power off the system, or possibly unplug the usb port.

    Regarding simulation + that realm -- the whole point of my experimenting
    with VHDL and I expect yours as well is to create code that will actually
    get loaded onto actual hardware. Textbooks on VHDL seem often to
    suffer from a horrible defect -- they imply VHDL is itself a programming
    language someone would use for its own right. What a joke.

    The only VHDL code I'll be creating is synthesizable code, I'd hope.
    All this
    X := '1' after 1ns;
    Riiiiiight. Make it look pretty + realistic on a simulation. But that's
    not synthesizable.

    It'd be nice to just cut out all the textbooks say about non-synthesizable
    VHDL and move that to an appendix or something. Cut through all the
    crap that I'm not going to use anyway. Just give me the meat. I already
    know how to program.

    Whatever works for you, go with it. It's easy to give up with learning
    VHDL. My own involvement goes in fits and starts. Very frustrating,
    actually.

    Good luck. I don't think I've helped much though.

    -Dave
     
    David Ashley, Aug 15, 2006
    #3
  4. a

    KJ Guest

    David Ashley wrote:
    > The only VHDL code I'll be creating is synthesizable code, I'd hope.
    > All this
    > X := '1' after 1ns;
    > Riiiiiight. Make it look pretty + realistic on a simulation. But that's
    > not synthesizable.
    >
    > It'd be nice to just cut out all the textbooks say about non-synthesizable
    > VHDL and move that to an appendix or something. Cut through all the
    > crap that I'm not going to use anyway. Just give me the meat. I already
    > know how to program.


    What is or isn't synthesizable though is to a large degree just a
    function of the technology of the day that is used to implement the
    code. Even X <= Y after 1ns is synthesizable. It's called a delay
    line, they do exist just maybe not inside your garden variety CPLD or
    FPGA but if given enough market demand they certainly will be all over
    the place.

    Now of course the ASIC folks can synthesize darn near anything and when
    you think about it, anything that has been built has been synthesized
    but you (me and most other people) when yacking about
    'non-synthesizable' code now-a-days are usually referring to what can
    be synthesized into an FPGA. Here is a short list off the top of my
    head that couldn't be synthesized into early FPGA/CPLDs but 25 years
    later can.

    - Decent size memory (~Couple of KB, LUTs, RAM, ROM for various tasks).
    - Phase locked loops
    - A/D Converters
    - D/A Converters

    Some other points are:
    - The stuff you shove over into the appendix as being not synthesizable
    will in many cases be synthesizable in a few years. Well, OK type
    'real' and 'time' might be m-a-n-y years out.

    - Assertion checking is never going to be synthesizable....but is dang
    handy just about everywhere (inside your design code, outside in the
    simulation model of the stuff surrounding the design you're testing).
    While waveform viewing will probably always be useful for debug of a
    known problem, assertion checking is replacing waveform viewing for
    finding those problems in the first place. For many people, myself
    included, would change "is replacing" to "has almost completely
    replaced" in the previous sentence....depends on the designer.

    - That non-synthesizable stuff comes in mighty handy when modelling
    those other pesky parts that surround your FPGA/CPLD. If you're not
    taking advantage of that modelling capability today and instead are
    forcing/scripting I/O to the design that you're testing than you're
    probably doing things the hard way.

    Add some simulation models and assertion checking and use that
    non-synthesizable stuff and you'll find you're flying higher than some
    of the others.

    KJ
     
    KJ, Aug 15, 2006
    #4
  5. a

    David Ashley Guest

    KJ wrote:
    >...
    > - That non-synthesizable stuff comes in mighty handy when modelling
    > those other pesky parts that surround your FPGA/CPLD. If you're not
    > taking advantage of that modelling capability today and instead are
    > forcing/scripting I/O to the design that you're testing than you're
    > probably doing things the hard way.
    >
    > Add some simulation models and assertion checking and use that
    > non-synthesizable stuff and you'll find you're flying higher than some
    > of the others.
    >
    > KJ
    >


    KJ,

    Lots of interesting points. I think the "assert" can certainly be useful
    as you describe. One thing to note is that it would be very very much
    easier to code expected behaviour in 'c' or 'c++' than in vhdl. If we're
    talking about non-synthesizable code being used to verify the
    synthesizable code, then VHDL wouldn't be my first choice. I think I
    heard there is movement towards embedding 'c' code within VHDL or
    some hybrid approach or something, just for this issue.

    Another issue of simulation vs actual use -- I have in mind an application
    for an FPGA where the FPGA is the main brain of a multimedia system,
    including audio, video, networking, etc. The chips I want to use to
    connect to the fpga are from various suppliers. How can I hope to
    simulate this whole system? Some of the chips are made in Taiwan --
    sketchy to no documentation and I'd be very surprised if they
    provided any simulation models.

    So the only way to debug this thing is through using actual hardware,
    doing things in real time since it will require human interaction.

    So I guess the dividing line isn't so much as what is synthesizable as
    what am I actually going to be doing with VHDL instead of with a
    more familiar (to me) language. All I want VHDL for is to help create
    the bit file I'll be downloading into the FPGA to make the device do
    what it needs to do...I'm not interested in the intellectual exercise of
    implementing ELIZA in VHDL :^).

    > - Decent size memory (~Couple of KB, LUTs, RAM, ROM for various tasks).
    > - Phase locked loops
    > - A/D Converters
    > - D/A Converters


    Other stuff moved onto the fpga fabric -- embedded processors,
    multipliers, MAC's perhaps. Special output buffers to handle DDR2
    memory signals.

    -Dave
     
    David Ashley, Aug 15, 2006
    #5
  6. a

    KJ Guest

    "David Ashley" <> wrote in message
    news:44e23aa3$...
    > KJ wrote:
    >>...
    >> - That non-synthesizable stuff comes in mighty handy when modelling
    >> those other pesky parts that surround your FPGA/CPLD. If you're not
    >> taking advantage of that modelling capability today and instead are
    >> forcing/scripting I/O to the design that you're testing than you're
    >> probably doing things the hard way.
    >>
    >> Add some simulation models and assertion checking and use that
    >> non-synthesizable stuff and you'll find you're flying higher than some
    >> of the others.
    >>
    >> KJ
    >>

    >
    > KJ,
    >
    > Lots of interesting points. I think the "assert" can certainly be useful
    > as you describe. One thing to note is that it would be very very much
    > easier to code expected behaviour in 'c' or 'c++' than in vhdl.


    Not necessarily any easier in c/c++. Inside a non-synthesizable model
    you're only interested in modelling the behaviour somewhat and in that
    context you generally have the freedom to code everything in a single
    process (or a handful at best) and make it look very 'c-like'. If you want
    to code in c/c++ than probably you want SystemC and then of course a mixed
    language simulation environment.

    > If we're
    > talking about non-synthesizable code being used to verify the
    > synthesizable code, then VHDL wouldn't be my first choice. I think I
    > heard there is movement towards embedding 'c' code within VHDL or
    > some hybrid approach or something, just for this issue.
    >

    I think you may be talking about mixing SystemC and VHDL or Verilog or
    SystemVerilog. Every language has it's proponents, plusses and minuses and
    such. I wouldn't call it a movement just that one needs to cope with
    integrating code written in various languages. Since each language 'seems'
    to all be evolving and have some users it suggests that each has a niche and
    over time the ebb and flow of which language fits best under certain design
    conditions will vary.

    > Another issue of simulation vs actual use -- I have in mind an application
    > for an FPGA where the FPGA is the main brain of a multimedia system,
    > including audio, video, networking, etc. The chips I want to use to
    > connect to the fpga are from various suppliers. How can I hope to
    > simulate this whole system? Some of the chips are made in Taiwan --
    > sketchy to no documentation and I'd be very surprised if they
    > provided any simulation models.


    Ideally the supplier would supply a model, but if they don't you can do it
    yourself. But you don't need to code up a model for general use by anyone,
    just something good enough for your use. I'm in a similar situation in that
    I use ASICs with no sim model from the vendor but I do know what the I/O
    pins are supposed to be doing and can model some form of behaviour that
    validates that information is properly flowing around the system. As an
    example, one of the part I use is a Philips processor. I don't have a
    'real' model for the processor and I don't run the 'real' code, instead what
    my VHDL model does is emulate the two together. From the standpoint of an
    external viewer of the signal pins (which is what your FPGA is) it doesn't
    know or care how that model gets generated.

    Having said that though, by modelling the part yourself, you're also putting
    yourself in the situation of wanting to validate that the model is at least
    accurate enough for your purposes. But I would argue that you are
    implicitly doing this anyway with whatever form of stimulus/expected
    response set that you come up with. By putting this explicitly in the form
    of a simulation model you're just changing the form that you encode that
    knowledge and if you try it out you may find that it's roughly the same
    level of effort.

    The other thing I do is use an accurate board model. Our CAD system, when
    you save a schematic also writes out a VHDL model that can be used in
    simulation as well. If you're new to trying to "model the entire system" I
    wouldn't suggest starting at this point until you've gotten your feet wet by
    writing your own VHDL that plops down part X, Y and Z and your FPGA and then
    interconnecting them (and of course writing/scrounging sim models for X, Y
    and Z). Using the CAD produced VHDL model is the most accurate but requires
    the most models and you'll find yourself fighting seemingly 'stupid' things
    like resistor models (like what is the logical value of a net with a
    pullup/pulldown termination; or what about that resistor that connects two
    ends of a differential pair).

    The last thing I do is that the board typically is not the entire system
    either. It connects to external devices....so I model them as well and
    connect them to the CAD produced simulation model.
    >
    > So the only way to debug this thing is through using actual hardware,
    > doing things in real time since it will require human interaction.
    >

    I agree to a point. But if you go into the debug phase with a solid feel
    for what you believe parts X, Y and Z 'should' be doing based on your
    simulation model and whatever knowledge of the part you have you can go
    about the debug more quickly.

    Eventually of course you run across the situation where the real parts are
    not behaving as you thought they should and of course it is causing some
    actual problem on the board that you have to fix. What this implies then is
    that either the simulation model was not quite as complete as you need it to
    be or that your testing didn't exercise things in the manner that the real
    part does on your board. Sometimes the problem is a relatively simple one
    where you can with confidence put in the FPGA design change and fix the
    problem.

    For the not so easy problems though you should 'fix' the simulation model by
    adding the new behaviour that you're actually seeing and then you should
    also be able to see the failure that you're seeing on the board (even more
    ideally because you added an 'assert' to catch it) and debug in a simulation
    environment from there. Simulation time is w--a--y longer than real time
    but the simulation environment lets you probe down to every blasted signal
    in your design to get at the root cause of a problem. Debug in hardware
    either doesn't allow this luxury or when it does (i.e. bringing out internal
    nodes to observable pins) is limited because you go through various
    iterations bringing out more and more new and interesting signals whereas in
    simulation you just drag the new signal over to the wave window and can
    immediately see the entire history of that signal.

    > So I guess the dividing line isn't so much as what is synthesizable as
    > what am I actually going to be doing with VHDL instead of with a
    > more familiar (to me) language. All I want VHDL for is to help create
    > the bit file I'll be downloading into the FPGA to make the device do
    > what it needs to do...I'm not interested in the intellectual exercise of
    > implementing ELIZA in VHDL :^).


    And if there is no need for design verification prior to build then you're
    right you don't need any of this so you could've stopped reading this long
    ago ;)

    >
    >> - Decent size memory (~Couple of KB, LUTs, RAM, ROM for various tasks).
    >> - Phase locked loops
    >> - A/D Converters
    >> - D/A Converters

    >
    > Other stuff moved onto the fpga fabric -- embedded processors,
    > multipliers, MAC's perhaps. Special output buffers to handle DDR2
    > memory signals.


    Yep, the list goes on and on.

    KJ
     
    KJ, Aug 16, 2006
    #6
  7. a

    Guest

    a wrote:
    > Howdy all -
    >
    > At any rate, I have a programmer that can do smaller DIP parts and
    > picked up some 22CV10 PEEL devices and would like to generate a
    > JEDEC fuse file for them. Sure, they're small parts and all, and
    > VHDL/Verilog is overkill for them, but I'm learning and why not?
    > I see no reason not to use an HDL for decoders and so forth.
    >
    > Thanks,
    >
    > Rick
    >


    What you want is a package called "Cypress Warp".

    With that package, you can generate JED files for PALs & GALs in VHDL
    or Verilog. It even has a rudimentary simulator.

    Good luck finding one, Cypress stopped selling it a while back.
     
    , Aug 17, 2006
    #7
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Christopher Bunk

    Synthesis of STD_LOGIC

    Christopher Bunk, Jul 1, 2003, in forum: VHDL
    Replies:
    2
    Views:
    1,311
    Tim Hubberstey
    Jul 4, 2003
  2. Mike
    Replies:
    3
    Views:
    3,062
    Mike Treseler
    Jul 9, 2003
  3. walala
    Replies:
    4
    Views:
    2,115
    Ralf Hildebrandt
    Sep 8, 2003
  4. walala
    Replies:
    4
    Views:
    1,203
    Technology Consultant
    Sep 9, 2003
  5. rkdkkr

    22v10

    rkdkkr, Apr 2, 2014, in forum: VHDL
    Replies:
    0
    Views:
    208
    rkdkkr
    Apr 2, 2014
Loading...

Share This Page