Statemachine working on Xilinx but not on Altera....

Discussion in 'VHDL' started by Stefan Oedenkoven, Sep 11, 2004.

  1. Hi Ng,

    i have a statemachine which should do some action on a sensor-signal 'sX'


    pSYNC_PROC: process (CLK, Reset)
    begin
    if (Reset='0') then
    sCurrentState <= U001;
    elsif (CLK'event and CLK = '1') then
    sCurrentState <= sNextState;
    end if;
    end process;

    pCOMB_PROC: process (Reset, sCurrentState, sX, sY)
    variable vX_read : STD_LOGIC := '0';
    begin
    if Reset = '0' then
    sNextState <= U001;
    else

    case sCurrentState is

    when U001 =>
    if sX = '0' then
    sNextState <= U002;
    vX_read := '1';
    else
    sNextState <= U001;
    end if;

    when U002 =>
    if sX = '1' then
    vX_read := '0'; -- ok, now Signal sX was again high,
    so the next falling edge will be used
    sNextState <= U002;
    elsif sX = '0' then
    if vX_read = '0' then
    vX_read := '1'; -- this is only working on XilinxISE
    and XV9500 ... with Altera Quartus and 10K-Series i never leave U002!
    why???
    sNextState <= U003;
    else
    sNextState <= U002;
    end if;
    end if;

    when U003 =>
    ....
    ....


    Is this the right way to handle asynchronous signals???

    thanks in advance,
    Stefan
     
    Stefan Oedenkoven, Sep 11, 2004
    #1
    1. Advertising

  2. Stefan Oedenkoven wrote:

    > when U001 =>
    > if sX = '0' then
    > sNextState <= U002;
    > vX_read := '1';


    Ok, going to state 2, and vX_read will be '1'. Let's assume that sX stays
    '0'...

    > when U002 =>

    ....
    > elsif sX = '0' then
    > if vX_read = '0' then
    > vX_read := '1'; -- this is only working on XilinxISE
    > and XV9500 ... with Altera Quartus and 10K-Series i never leave U002!
    > why???
    > sNextState <= U003;
    > else
    > sNextState <= U002;
    > end if;
    > end if;


    With sX being '0', and vX_read being '1', you will always remain in state 2.
    If sX will become '1', then vX_read will become '0', and if sX becomes '0'
    again after that, _then_ you'll get out of state 2.

    So, the question is: what happens? Unless the sequence above is followed, it
    appears to me that Altera is handling this correctly.

    Now if sX is asynchronous, then I fear for the functionality of your FSM.
    Timing will be impossible to get correct, and the behaviour may be _not_
    what you intended. The _least_ you need to do is clock sX in twice before
    you use its value.

    Regards,

    Pieter Hulshoff
     
    Pieter Hulshoff, Sep 11, 2004
    #2
    1. Advertising

  3. Hi Pieter,

    yep that was the problem - even with sX switching many times high - low -
    high etc... it remained in state 2...

    after some testing i came to this assumptions:
    1) -- stupid example:
    when state001 =>
    sX <= '1';
    sNextState <= state002;
    when state002 =>
    if sX = '1' then
    sNextState <= state002;
    else
    sNextState <= state001;
    end;
    a)The signal assignment from state001 with Xilinx ISE and CPLD XV9500 will
    still be the same in state002.
    b) With Altera Quartus and FPGA 10K the signal must again be assigned in
    state002, if i need there sX='1'.


    2)
    -- vTest is 1
    if vTest = 1 then
    sNextState <= state002;
    vTest := 0;
    end if;
    a) with quartus and XV9500 i get this sequence:
    assign sNextState <= state002; assign variable vTest the value 0 and in the
    next clock cycle go to state002 (with the statemachine-version i posted)
    b) with Altera and 10K:
    sNextState seems to get 'hardwired' like sNextState <= state002 when vTest =
    1 .
    That means immediatly when vTest is set back to 0, sNextState will not be
    state002 any more..


    It would be nice, if you could comment this... and tell me, if that's the
    behaviour you would expect or is it caused by the different Synthesizers or
    different Hardware...

    regards,
    Stefan


    "Pieter Hulshoff" <> schrieb im Newsbeitrag
    news:4143300e$0$35778$4all.nl...
    > Stefan Oedenkoven wrote:
    >
    > > when U001 =>
    > > if sX = '0' then
    > > sNextState <= U002;
    > > vX_read := '1';

    >
    > Ok, going to state 2, and vX_read will be '1'. Let's assume that sX stays
    > '0'...
    >
    > > when U002 =>

    > ...
    > > elsif sX = '0' then
    > > if vX_read = '0' then
    > > vX_read := '1'; -- this is only working on

    XilinxISE
    > > and XV9500 ... with Altera Quartus and 10K-Series i never leave U002!
    > > why???
    > > sNextState <= U003;
    > > else
    > > sNextState <= U002;
    > > end if;
    > > end if;

    >
    > With sX being '0', and vX_read being '1', you will always remain in state

    2.
    > If sX will become '1', then vX_read will become '0', and if sX becomes '0'
    > again after that, _then_ you'll get out of state 2.
    >
    > So, the question is: what happens? Unless the sequence above is followed,

    it
    > appears to me that Altera is handling this correctly.
    >
    > Now if sX is asynchronous, then I fear for the functionality of your FSM.
    > Timing will be impossible to get correct, and the behaviour may be _not_
    > what you intended. The _least_ you need to do is clock sX in twice before
    > you use its value.
    >
    > Regards,
    >
    > Pieter Hulshoff
    >
     
    Stefan Oedenkoven, Sep 11, 2004
    #3
  4. Stefan

    Infering your requirement and in ignorance of your clock speed ...

    I infer thet you are waiting for an ack signal, which you wish to see
    asserted for two clock cycles.

    Firstly, some good practice observations:
    0) don't create latches, such as vX_read by implying 'memory' in unclocked
    processes
    1) staticise the (asynchronous) input signal sX through two FF clocked by
    CLK
    2) don't use variables for non-combinatorial logic inside processes, they
    are signals treat them as such
    3) don't initialise variables in VHDL intended for synthesis, except by
    reseting; it can lead to simulation / synthesis missmatches. Initialisation
    is, to the first order, for testbenches.

    Secondly, some opinions on good practice:
    1) put the whole synchronous state machine, now that vX_read has been
    synchronised, in one process
    2) consider using registers for your state derived outputs (not that you
    show any), less delay and less skew
    3) use a variable for next state and assign it to state "at the end" of the
    process; you can use the variable to the generate any state derived outputs
    4) examine carefully and report, to the Ng if appropriate, what the
    synthesiser generated and the simulator said; as with all computers design
    intent is simply a miss-representation of the specification, what matters is
    what the computer decided to do therefore read the listings / reports not
    the source code

    To respond to your narrow query "Is this a good way of handling asynchronous
    signals ?" No

    I suggest that you:
    a) use two FF to staticise the asynchronous signal, addressing metastability
    issues
    b) add a third FF and use FF_2 = '1' and FF_3 ='0' as your detection
    condition; i.e. look for the rising edge.
    c) use another state to encode the armed condition, if you really require to
    look for two ones
    d) recast the entire FSM as a single synchronous process (now that it's
    inputs are synchronous)
    e) consider which encoding (binary, 1-hot, Gray) is appropriate for the FSM

    Now, if the asynchronous signal is less than several clocks wide or if the
    clock frequency or latency requirements are "challenging" the foregoing may
    be inapplicable. If so, you could perhaps use a Gray coded state machine
    with a single input, and an agressive validation programme. If you do
    please report the outcome in the literature.

    I hope this is of assistance

    Martin

    "Stefan Oedenkoven" <> wrote in message
    news:...
    > Hi Ng,
    >
    > i have a statemachine which should do some action on a sensor-signal 'sX'
    >
    >
    > pSYNC_PROC: process (CLK, Reset)
    > begin
    > if (Reset='0') then
    > sCurrentState <= U001;
    > elsif (CLK'event and CLK = '1') then
    > sCurrentState <= sNextState;
    > end if;
    > end process;
    >
    > pCOMB_PROC: process (Reset, sCurrentState, sX, sY)
    > variable vX_read : STD_LOGIC := '0';
    > begin
    > if Reset = '0' then
    > sNextState <= U001;
    > else
    >
    > case sCurrentState is
    >
    > when U001 =>
    > if sX = '0' then
    > sNextState <= U002;
    > vX_read := '1';
    > else
    > sNextState <= U001;
    > end if;
    >
    > when U002 =>
    > if sX = '1' then
    > vX_read := '0'; -- ok, now Signal sX was again high,
    > so the next falling edge will be used
    > sNextState <= U002;
    > elsif sX = '0' then
    > if vX_read = '0' then
    > vX_read := '1'; -- this is only working on XilinxISE
    > and XV9500 ... with Altera Quartus and 10K-Series i never leave U002!
    > why???
    > sNextState <= U003;
    > else
    > sNextState <= U002;
    > end if;
    > end if;
    >
    > when U003 =>
    > ....
    > ....
    >
    >
    > Is this the right way to handle asynchronous signals???
    >
    > thanks in advance,
    > Stefan
    >
    >
    >
    >
     
    Martin Bishop, Sep 11, 2004
    #4
  5. Hello Stefan,

    > yep that was the problem - even with sX switching many times high - low -
    > high etc... it remained in state 2...


    Ah, things seem to be clear to me now. You see: from a VHDL point of view,
    the code is indeed what you intend. The problem is: you're defining
    hardware here, and you've defined a value to be stored (vX_read) within a
    combinatorial process. Your intention seems to be to have this value stored
    in a FlipFlop, but you have not described such in your code.

    The Xilinx toolkit seems to understand the intention behind your code. The
    Altera toolkit figured you just wanted to define a combinatorial loop. In
    this case the Xilinx toolkit is correct, but under different circumstances
    this might not have been the case.

    The solution is to define signals vX_read and vX_read_next, and treat them
    the same as sCurrentState and sNextState.

    Regards,

    Pieter Hulshoff
     
    Pieter Hulshoff, Sep 11, 2004
    #5
  6. Hi Martin & Pieter,

    thanks for your comments...

    > Firstly, some good practice observations:
    > 2) don't use variables for non-combinatorial logic inside processes, they
    > are signals treat them as such.

    so variables are simply synthesized to latches? if not - when do i use
    variables or should i avoid them generally?

    >
    > Secondly, some opinions on good practice:
    > 1) put the whole synchronous state machine, now that vX_read has been
    > synchronised, in one process

    so, then i need only one signal for the state assignment...

    > 2) consider using registers for your state derived outputs (not that you
    > show any), less delay and less skew

    registers? hmmm it's optional for the signal declaration, right? but i
    didn't find anything about this in my vhdl book. Will register-signals
    always synthesized to flip-flops? where is the difference to a 'normal'
    signal?

    > 3) use a variable for next state and assign it to state "at the end" of

    the
    > process; you can use the variable to the generate any state derived output
    > a) use two FF to staticise the asynchronous signal, addressing

    metastability
    > issues
    > b) add a third FF and use FF_2 = '1' and FF_3 ='0' as your detection
    > condition; i.e. look for the rising edge.

    why is it not sufficient to use two FFs and wait for FF_1 = '1' and FF_2 =
    '0'

    > c) use another state to encode the armed condition, if you really require

    to
    > look for two ones

    erm, what did you mean?
    > e) consider which encoding (binary, 1-hot, Gray) is appropriate for the

    FSM
    ok, my literature say's for CPLD is binary and for FPGA is 1-hot is
    appropriate.

    ok if i programm a CPLD / FPGA and don't be aware of the exact timings i
    should alway avoid asynchronous inputs to FSMs - did i catch this right?

    > I hope this is of assistance

    yes, thanks ;)
    >
    > Martin
     
    Stefan Oedenkoven, Sep 12, 2004
    #6
  7. > so variables are simply synthesized to latches? if not - when do i use
    > variables or should i avoid them generally?


    Variables and signals are synthesized into latches or FFs if they need to
    carry their value beyond the current time. Whether they become latches or
    FFs depend on if they're level sensitive (latches) or edge sensitive (FFs);
    in other words: when do they get their value?

    In general I avoid using variables in all cases, unless it is to temporarily
    calculate a value I'll be needing a lot in the code (readability).
    Variables are usually a pain to find back in the netlist, and are often
    hard to trace within simulation (depends on the tool).

    >> Secondly, some opinions on good practice:
    >> 1) put the whole synchronous state machine, now that vX_read has been
    >> synchronised, in one process

    > so, then i need only one signal for the state assignment...


    If you have one synchronized process? Yes, you'd only need one signal for
    the state assignment.

    > why is it not sufficient to use two FFs and wait for FF_1 = '1' and FF_2
    > = '0'


    You need two FFs for metastability. Any edge detection must be done using
    FFs after the 1st, so the 2nd and 3rd would be usable like Martin
    described. Only one FF should be connected to the 1st FF, or you can see
    some very interesting behaviour of your design.

    > ok, my literature say's for CPLD is binary and for FPGA is 1-hot is
    > appropriate.


    I see little reason for using 1 hot encoding. If every part of your design
    is synchronous, it doesn't really matter what coding is used, unless you
    want it to be used for error detection later on.

    > ok if i programm a CPLD / FPGA and don't be aware of the exact timings i
    > should alway avoid asynchronous inputs to FSMs - did i catch this right?


    I'm from the school that believes asynchronous designs should be outlawed.
    They're an incredible pain to get to work, and even if by some divine
    intervention you get a working design you can never be sure it will still
    work when you port it to a different technology. About the only thing they
    have in favour is they tend to use less power. IF you can get it to work
    that is...

    Regards,

    Pieter Hulshoff
     
    Pieter Hulshoff, Sep 12, 2004
    #7
  8. Stefan

    0) I've interleaved responses to your specific points below.

    1) A sketch of an FSM with a Request input, a Strobe output and an Ack input
    follows [E&OE]

    No testbench, no syntax check, no testing and no warranty.

    Note that, as the clock is continuous, I've used synchronous resets; you
    always should when you can.

    State encoding, timeout, illegal state recovery and post synthesis V&V
    are left as exercises for the reader.

    Hope this is of assistance

    Martin


    entity FSM
    is port (Rst_n : in Std_Logic;
    Clk : in Std_Logic;
    Request : in Std_Logic; -- usually this would be negative
    active
    Strobe : out Std_Logic;
    Ack : in Std_Logic);
    end FSM;

    architecture Synthesisable of FSM
    is
    type tFSM is (FsmIdle, FsmAssert, FsmArmed);

    signal srFSM : tFSM;

    signal Rst_n_d1,
    Rst_n_d2,
    Request_d1,
    Request_d2,
    Request_d3,
    Ack_d1,
    Ack_d2 : Std_Logic;

    begin

    pSynchReset:
    process
    if Reset_n = '0'
    then Rst_n_d1 <= '0';
    Rst_n_d2 <= '0';
    elsif rising_edge (Clk)
    then Rst_n_d1 <= Rst_n;
    Rst_n_d2 <= Rst_n_d1;
    end if;
    end process pSynchReset;

    pSynchRequest:
    process

    wait for rising_edge (Clk);

    Request_d1 <= Request;
    Request_d2 <= Request_d1;
    Request_d3 <= Request_d2;

    end if;

    end process pSynchRequest;

    pSynchAck:
    process

    wait for rising_edge (Clk);

    Ack_d1 <= Ack;
    Ack_d2 <= Ack_d1;

    end if;

    end process pSynchAck;

    pFSM:
    process

    var vFSM : tFSM;

    begin

    wait for rising_edge(Clk);

    vFSM := srFSM;

    if Rst_n_d2 = '0'
    then vFSM := FsmIdle;
    else case srFSM is

    when FsmIdle
    => if (Request_d1 xor Request_d2) = '1' -- Request line
    toggles to initiate FSM
    then vFSM := FsmAssert;
    end if;

    when FsmAssert
    => if (Ack_d2 = '1') and (Ack_d3 = '0') -- wait for
    rising edge on Ack
    then vFSM := FsmArmed;
    end if;

    when FsmArmed
    => if Ack_d3 = '1' -- wait for two 'samples' of Ack
    (intentionally clumsy)
    then vFSM := FsmIdle;
    end if;

    when others
    => assert ...

    end case srFSM;

    end if;

    srFSM <= vFSM; -- location imaterial, as long as it's after the wait

    case vFSM is -- vFSM to update State and Strobe simulatneously

    when FsmIdle
    => Strobe <= '0';

    when FsmAssert,
    FsmArmed
    => Strobe <= '1';

    when others
    => assert ...

    end case;

    end process; -- pFSM

    end Synthesisable; -- of FSM


    "Stefan Oedenkoven" <> wrote in message
    news:...
    > Hi Martin & Pieter,
    >
    > thanks for your comments...
    >
    > > Firstly, some good practice observations:
    > > 2) don't use variables for non-combinatorial logic inside processes,

    they
    > > are signals treat them as such.

    > so variables are simply synthesized to latches? if not - when do i use
    > variables or should i avoid them generally?


    Yes, variables which implement sequential logic (requiring memory) inside
    proceses will be synthesised as latches or flip flops; usually you don't
    want to synthesise latches, and the implicit synthesis of flip flops leaves
    details such as reset (perhaps) indeterminate.

    A good use for variables, IMHO, is for intermediate combinatorial results;
    e.g. next state

    >
    > >
    > > Secondly, some opinions on good practice:
    > > 1) put the whole synchronous state machine, now that vX_read has been
    > > synchronised, in one process

    > so, then i need only one signal for the state assignment...


    Not certain what you mean. But, the vX_read logic would be subsumed into
    the FSM

    >
    > > 2) consider using registers for your state derived outputs (not that you
    > > show any), less delay and less skew

    > registers? hmmm it's optional for the signal declaration, right? but i
    > didn't find anything about this in my vhdl book. Will register-signals
    > always synthesized to flip-flops? where is the difference to a 'normal'
    > signal?


    Register = flip flop (in this usage); the rationale for output registers is
    that the outputs occur after Tclock-to-output rather than Tdata-to-output.
    Or, in Mealy / Moore argot: use a Moore machine [see e.g. Cohen, ISBN
    0-7923-8474-1 p299]

    >
    > > 3) use a variable for next state and assign it to state "at the end" of

    > the
    > > process; you can use the variable to the generate any state derived

    output
    > > a) use two FF to staticise the asynchronous signal, addressing

    > metastability
    > > issues
    > > b) add a third FF and use FF_2 = '1' and FF_3 ='0' as your detection
    > > condition; i.e. look for the rising edge.

    > why is it not sufficient to use two FFs and wait for FF_1 = '1' and FF_2

    =
    > '0'


    Metastability will (eventually) bite if you don't use a 'synchroniser',
    hence the 'extra' FF; use Google to find references e.g. from the silicon
    vendors and FAQs

    >
    > > c) use another state to encode the armed condition, if you really

    require
    > to
    > > look for two ones

    > erm, what did you mean?


    What I mean is are you looking for the 0/1 transition or for 0/1/1, as
    sugested by your initial posting

    > > e) consider which encoding (binary, 1-hot, Gray) is appropriate for the

    > FSM
    > ok, my literature say's for CPLD is binary and for FPGA is 1-hot is
    > appropriate.


    Hmm, those are the default but not necessarily apropriate encodings. If
    your design is more than an example, you should read up on this.

    >
    > ok if i programm a CPLD / FPGA and don't be aware of the exact timings i
    > should alway avoid asynchronous inputs to FSMs - did i catch this right?


    Absolutely, synchronise everything that enters clocked logic including
    reset. Or, you're playing hardball.

    >
    > > I hope this is of assistance

    > yes, thanks ;)
    > >
    > > Martin

    >
    >
     
    Martin Bishop, Sep 12, 2004
    #8
  9. Re: Statemachine - Errata and Addendum

    0) Errata is engrossed in the example for known lint; denoted by DTGs
    [e.g. -- 12 2200A Sep 04]

    1) A very good collection of papers on Verilog, synthesis and ..., can be
    found at www.sunburst-design.com/papers

    2) CummingsSNUG2002SJ_Resets_rev1_1.pdf [OpCit] discusses Async and Sync
    resets and includes VHDL examples.

    3) Cohen [ISBN 0-7923-8474-1 & 0-7923-8115-7] discusses coding styles for
    (synchronous) FSMs.

    Martin


    entity FSM
    is port (Rst_n : in Std_Logic;
    Clk : in Std_Logic;
    Request : in Std_Logic; -- usually this would be negative
    active
    Strobe : out Std_Logic;
    Ack : in Std_Logic);
    end FSM;

    architecture Synthesisable of FSM
    is
    type tFSM is (FsmIdle, FsmAssert, FsmArmed);

    signal srFSM : tFSM;

    signal Rst_n_d1,
    Rst_n_d2,
    Request_d1,
    Request_d2,
    Request_d3,
    Ack_d1,
    Ack_d2 : Std_Logic;

    begin

    pSynchReset:
    process (Reset_n, Clk) -- 12 2200A Sep 04
    if Reset_n = '0'
    then Rst_n_d1 <= '0';
    Rst_n_d2 <= '0';
    elsif rising_edge (Clk)
    then Rst_n_d1 <= Rst_n;
    Rst_n_d2 <= Rst_n_d1;
    end if;
    end process pSynchReset;

    pSynchRequest:
    process

    wait until rising_edge (Clk); -- 12 2200A Sep 04

    Request_d1 <= Request;
    Request_d2 <= Request_d1;
    Request_d3 <= Request_d2;

    end if;

    end process pSynchRequest;

    pSynchAck:
    process

    wait until rising_edge (Clk); -- 12 2200A Sep 04

    Ack_d1 <= Ack;
    Ack_d2 <= Ack_d1;

    end if;

    end process pSynchAck;

    pFSM:
    process

    var vFSM : tFSM;

    begin

    wait until rising_edge (Clk); -- 12 2200A Sep 04

    vFSM := srFSM;

    if Rst_n_d2 = '0'
    then vFSM := FsmIdle;
    else case srFSM is

    when FsmIdle -- Request line toggles to initiate FSM
    => if (Request_d2 xor Request_d3) = '1' -- 12 2200A Sep
    04
    then vFSM := FsmAssert;
    end if;

    when FsmAssert
    => if (Ack_d2 = '1') and (Ack_d3 = '0') -- wait for
    rising edge on Ack
    then vFSM := FsmArmed;
    end if;

    when FsmArmed
    => if Ack_d3 = '1' -- wait for two 'samples' of Ack
    (intentionally clumsy)
    then vFSM := FsmIdle;
    end if;

    when others
    => assert ...

    end case srFSM;

    end if;

    srFSM <= vFSM; -- location imaterial, as long as it's after the wait

    case vFSM is -- vFSM to update State and Strobe simulatneously

    when FsmIdle
    => Strobe <= '0';

    when FsmAssert,
    FsmArmed
    => Strobe <= '1';

    when others
    => assert ...

    end case;

    end process; -- pFSM

    end Synthesisable; -- of FSM
     
    Martin Bishop, Sep 12, 2004
    #9
  10. thanks

    Hi Pieter & Martin...

    ....wanted just to thank you for your help.
    For the moment Altera Quartus is synthesizing as i want it ;)

    best regards,
    stefan
     
    Stefan Oedenkoven, Sep 13, 2004
    #10
  11. Pieter Hulshoff wrote:

    > Variables and signals are synthesized into latches or FFs if they need to
    > carry their value beyond the current time. Whether they become latches or
    > FFs depend on if they're level sensitive (latches) or edge sensitive (FFs);
    > in other words: when do they get their value?


    Note that a synchronous process cannot generate latches
    and an a combinational process cannot generate flops.

    > In general I avoid using variables in all cases, unless it is to temporarily
    > calculate a value I'll be needing a lot in the code (readability).
    > Variables are usually a pain to find back in the netlist, and are often
    > hard to trace within simulation (depends on the tool).


    This is a matter of style.
    I use process variables except
    for inter-process communication because
    of the improved readability of sequential
    value creation.

    Using process labels makes it much easier
    to find and display local signal and variable waveforms.


    > I see little reason for using 1 hot encoding. If every part of your design
    > is synchronous, it doesn't really matter what coding is used,


    I agree.

    > I'm from the school that believes asynchronous designs should be outlawed.


    No need for a law.
    Such a design provides
    its own punishment,
    then enlightenment.


    -- Mike Treseler
     
    Mike Treseler, Sep 14, 2004
    #11
  12. Martin Bishop wrote:

    > 1) A sketch of an FSM with a Request input, a Strobe output and an Ack input
    > follows [E&OE]
    >
    > No testbench, no syntax check, no testing and no warranty.


    Consider cleaning this up a bit and reposting.
    I think it would be an excellent example without
    the syntax and type errors.

    -- Mike Treseler
     
    Mike Treseler, Sep 14, 2004
    #12
    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. Ronny Hengst

    Altera to Xilinx

    Ronny Hengst, Jul 24, 2003, in forum: VHDL
    Replies:
    1
    Views:
    2,376
    Andras Tantos
    Jul 24, 2003
  2. bobrics
    Replies:
    5
    Views:
    2,539
    bobrics
    Mar 7, 2005
  3. VHDL-BEGINNER

    Xilinx-altera-problem

    VHDL-BEGINNER, Nov 14, 2006, in forum: VHDL
    Replies:
    2
    Views:
    623
    VHDL-BEGINNER
    Nov 19, 2006
  4. chaitu
    Replies:
    1
    Views:
    822
  5. hayaloo

    Altera VS Xilinx

    hayaloo, Jul 25, 2009, in forum: VHDL
    Replies:
    0
    Views:
    1,388
    hayaloo
    Jul 25, 2009
Loading...

Share This Page