UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Explorer
Explorer
9,651 Views
Registered: ‎04-16-2009

Enumerated type clock

There is a number types in VHDL and some of them are multivalued but real logic uses only two values. I created a custom multivalued type, which is used to represent signals temporarily. The clock never takes 3rd value, so a standard clock line can be used for it. As demonstrated below, only intermedate assignment based style (alt5) is synthesizable. Unfortunately, as explained in comp.lang.vhdl discussion, assignment introuduces a delta delay clock skew in simulation  and, thus, corrupts the simulation. The choice becomes: either code for synthesis or code for simulation, which contradicts to the idea of HDL. Can this be fixed?

 

The following reveals the synthesis result (see comments next to wait statement) . I try Altera meantime.

 


library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
entity FF is
port (
signal CLK: std_logic;
D: in std_logic;
Q: out std_logic
);
end entity;

architecture BIVAL_WRAPPER of FF is

type TRIT is ('U', '0', '1');
function bit_equivalent(b: bit) return TRIT is
begin
CASE b IS
WHEN '0' => RETURN ('0');
WHEN '1' => RETURN ('1');
END CASE;
end;

FUNCTION To_bit ( a : TRIT; umap : BIT := '0') RETURN BIT IS
BEGIN
CASE a IS
WHEN '0' => RETURN ('0');
WHEN '1' => RETURN ('1');
WHEN OTHERS => RETURN umap;
END CASE;
END;

signal triCLK: TRIT;
signal reg1: std_logic;

constant ALTERNATIVE: integer := 1; -- sensing
begin
triCLK <= bit_equivalent(to_bit(CLK)); -- the temp tri-valued clk


ALT1: if (ALTERNATIVE = 1) generate
process begin
wait until to_bit(triCLK) = '1'; -- line 41: Bad condition in wait statement, or only one clock per process.
reg1 <= D;
end process;
end generate;


ALT2: if (ALTERNATIVE = 2) generate
process begin
wait until triCLK = '1'; -- line 0: Operands of <AND> are not of the same size.
reg1 <= D; -- which line?
end process;
end generate;

ALT3: if (ALTERNATIVE = 3) generate
process (triCLK) begin
if triCLK'EVENT and triCLK = '1' then --line 57: Operands of <AND> are not of the same size.
reg1 <= D;
end if;
end process;
end generate;

ALT4: if (ALTERNATIVE = 4) generate
signal R1_CLK: bit;
begin
R1_CLK <= to_bit(triCLK);

process begin
wait until bit_equivalent(R1_CLK) = '1'; -- line 68: Bad condition in wait statement, or only one clock per process.
reg1 <= D;
end process;
end generate;


ALT5: if (ALTERNATIVE = 5) generate
signal bi: bit;
begin
bi <= to_bit(triCLK);
process begin
wait until bi = '1'; --OK
reg1 <= D;
end process;
end generate;

Q <= reg1;

end architecture;

 

Message Edited by v_tihhomirov on 01-23-2010 11:46 AM
0 Kudos
15 Replies
Explorer
Explorer
9,625 Views
Registered: ‎07-27-2009

Re: Enumerated type clock

Hi,

 

Maybe you just want to stick with a very conventional way of writing sequential logic: a process with the clock (and reset) in the sensitivity list:

 

MAIN:process(clk, rst_n)

begin

  if rst_n='0' then

    output <= 0;

  elsif rising_edge(clk) then

    output <= input_a + input_b;

    -- etc etc etc

  end if;

end process MAIN;

 

If you don't want to handle multi-valued logic in your code, you can use boolean/integer/enum types in VHDL. For clock and reset nets, you want to stick as close as possible to the coding templates mentioned in your synthesis manuals. What might work with one tool, might not be supported with another and sooner or later you will be asked to map your code to another target, so you want to find a coding style that is widely supported instead of doing the opposite. This advise might safe you from a lot of frustration...

 

Cheers,

Johan

0 Kudos
Explorer
Explorer
9,616 Views
Registered: ‎04-16-2009

Re: Enumerated type clock

I have evalueated the approaches on Quartus II.

 

ALT1 and 5: OK

ALT2 and 4: double inv on the clock line. Here is how this "equality buffer" looks like on technology map:

 

 

ALT3 fails with a sensable message: attribute "EVENT" that is used for multiple bits is not synthesizable.

 

All the output is sensable and working ALT1 makes this "another target" a target of choice.

0 Kudos
Explorer
Explorer
9,613 Views
Registered: ‎04-16-2009

Re: Enumerated type clock

woutersj,

 

1. Have you ever looked at the ways tried, particularily ALT3 that involves the setsitivity list, before giving the advice? Do you mean that ALT3 fails because the async reset is not provided? Are you OK? What if I do not have any? It seems that even Quartus that supports all alternative ways does not support the way you argue for. Is it the target "compatibility" I need?

 

2. Regardelss of my need for multi-valued, do you see the title of the topic? Do you see that enum is already used to implement it?

Most free forum discussions frustrate my belief in humankind.
Message Edited by v_tihhomirov on 01-24-2010 08:49 AM
0 Kudos
Explorer
Explorer
9,584 Views
Registered: ‎07-27-2009

Re: Enumerated type clock

Read the reply again:

 

1. Use the synthesis templates understood by most synthesis tools. A template that is almost guaranteed to work on any synthesis tool I've ever encountered is the one mentioned in my original reply but taking into account that the clock is std_logic instead of some home brew 3-valued enum type.

 

2. This is the same as the previous: if the synthesis manuals talk about support for sequential processes with clock std_logic or  bit  or boolean and you stubbornly want to use something different and it fails then that probably also makes a statement on humankind.

 

 

Change your HDL code together with your attitude and you might actually end up with a working design.

 

Cheers,

Johan

0 Kudos
Historian
Historian
9,573 Views
Registered: ‎02-25-2008

Re: Enumerated type clock


v_tihhomirov wrote:

There is a number types in VHDL and some of them are multivalued but real logic uses only two values. I created a custom multivalued type, which is used to represent signals temporarily.


Real logic takes at least three values -- 0, 1 and high-Z. The unknown and the conflict are useful too. So this is why they invented std_logic. (signed and unsigned are essentially std_logic_vector with math extensions.)

 

 


The clock never takes 3rd value, so a standard clock line can be used for it. As demonstrated below, only intermedate assignment based style (alt5) is synthesizable. Unfortunately, as explained in comp.lang.vhdl discussion, assignment introuduces a delta delay clock skew in simulation  and, thus, corrupts the simulation. The choice becomes: either code for synthesis or code for simulation, which contradicts to the idea of HDL. Can this be fixed?

 

The following reveals the synthesis result (see comments next to wait statement) .


I suppose it's worth asking: What are you trying to do?

 


I try Altera meantime.


And that won't make any difference, because the language semantics remain the same.
----------------------------Yes, I do this for a living.
0 Kudos
Explorer
Explorer
9,566 Views
Registered: ‎04-16-2009

Re: Enumerated type clock

With my attitude I express that 1) disregarding my request and 2) recommending to accomplis nothing but a template is not really helpful/useful. Now, after I pulled you up, you have mentioned that I indeed use the enums, stopped to propose this "something different" and mock my choice of it instead. A statement on humankind is made under observations how people are incapable to keep track the previous post they respond on.
0 Kudos
Explorer
Explorer
9,569 Views
Registered: ‎04-16-2009

Re: Enumerated type clock

I do a logic emulator. It is going to support UNKNOWN values.
 

bassman59 wrote: 

 


I try Altera meantime.


And that won't make any difference, because the language semantics remain the same.

 

As you may see in my 2nd post, Altera performs much better.

0 Kudos
Teacher eilert
Teacher
9,552 Views
Registered: ‎08-14-2007

Re: Enumerated type clock

Hi bassman,

the problem of  v_tihhomirov has been stated in much more detail on comp.lang.vhdl.

And also been discussed there deeply.

 

To my understanding, he actualy has a problem with merging clock nets coded with different signal types(bit vs. std_logic).

These cause a delta delay when merged one way (due to  an implicit assignment) and no delta delay when using conversion functions.

 

Now he's inventing a U01 type which is incompatible to std_logic where we already have the subtypes X01 and UX01. Don't ask me why.

In my opinion, if a testbench fails because of delta delays, there's something wrong with the testbench (e.g. assigning signals at the same time the clock(s) change(s)),

but it may be more sophisticated than that, which is hard to say without a real code example that shows the problem.

 

    Regards

        Eilert

Message Edited by eilert on 01-26-2010 10:59 AM
0 Kudos
Teacher eilert
Teacher
9,550 Views
Registered: ‎08-14-2007

Re: Enumerated type clock

Hi,

you said : I do a logic emulator. It is going to support UNKNOWN values.

 

 In the std_logic_1164 package you find the following declaration:

 

type STD_ LOGIC is                        (  ‘U’,      -- Uninitialized

                                                             ‘X’,      -- Forcing Unknown

                                                            ‘0’,       -- Forcing   0

                                                            ‘1’,       -- Forcing   1

                                                            ‘Z’       -- High Impedance

                                                            ‘W’,     -- Weak     Unknown

                                                            ‘L’,      -- Weak     0

                                                            ‘H’,      -- Weak     1

                                                            ‘-’        -- don’t care

                                                          );

 

So I suspect what you really want is the already defined subtype X01, instead of your U01.

Otherwise you mix up the definitions for Unknown and Uninitialized.

 

Have a nice synthesis

  Eilert

 

0 Kudos
Explorer
Explorer
6,393 Views
Registered: ‎07-27-2009

Re: Enumerated type clock

If I understand correctly, this seems to be totally off-topic. You have something written in VHDL that has issues with delta cycles and you expect the synthesis tool to 'fix' this.

 

A number of options exist

  • ignore the unexpected synthesis result; garbage in/garbage out
  • write a linter to intercept this kind of known bad stuff
  • write a VHDL preprocessor that automatically fixes this by using a single type for clocks such that intermediate conversions are not needed
  • do a 100% emulation of the VHDL language semantics by adding delta cycle convergence signals to your cores


The best way to do it IMHO is to let the user fix the VHDL code by simply using 1 type for global nets. Having a conceptual identical clock with delta cycles will sooner or later result in simulation misery and a skilled VHDL writer is aware of this issue and should be capable of compensating delta cycle mismatches (ever tried to run a gated clock over a chip?).

 

Cheers,

Johan

0 Kudos
Explorer
Explorer
6,395 Views
Registered: ‎04-16-2009

Re: Enumerated type clock


eilert wrote:
To my understanding, he actualy has a problem with merging clock nets coded with different signal types(bit vs. std_logic).
Exactly.



These cause a delta delay when merged one way (due to  an implicit assignment) and no delta delay when using conversion functions. Now he's inventing a U10 type which is incompatible to std_logic where
we already have the subtypes X10 and UX10. Don't ask me why. In
my opinion, if a testbench fails because of delta delays, there's
something wrong with the testbench (e.g. assigning signals at the same
time the clock(s) change(s)), but it may be more sophisticated than that, which is hard to say without a real code example that shows the problem.

The assignment is not implicit. It is explicit and, as any assignment, introduces a delta-delay on clock line (clock skew). As clearly explained in VHDL usenet, this is not a fault of anybody; rather, it is a predetermined VHDL behaviour. All the code examples are given: both the skew-due-to-assignment (ALTERNATIVE 5 in my example) and skewless conversion-based approaches (ALT1 and 2 in my example). The skew on clock is a bad thing and I would like to avoid any descriptions that involve it. Particularily, ALT5, while synthesizes a proper FF, is modeled as <=D wire/process rather than FF because of the skew by the functional sim. VHDL is a imulation spec lang and it prefers either ALT1 or ALT2 for FF. Therefore, I want these two coding styles or something similar be synthesizable.

 

 

I see that my scarce explanations regarding logic emulation and why multivalued signals might be necessary in HW are not comprehended easily in the HW design community. A better one is given in "Encoded don’t-care value approach" in "Improved Fault Emulation for Synchronous Sequential Circuits", or "III. HANDLING THE UNKNOWN LOGIC VALUE" in Fault Emulation: A New Methodology for Fault Grading. Everybody on both comp.lang.vhdl and here asks me this question about std_logic subtyping, so I start to think that the enumerated (multivalued) types are popular only for simulation and rarely when synthesized (if intended for synthesis at all).

Message Edited by v_tihhomirov on 01-26-2010 05:11 AM
Message Edited by v_tihhomirov on 01-27-2010 03:43 AM
0 Kudos
Explorer
Explorer
6,390 Views
Registered: ‎04-16-2009

Re: Enumerated type clock


woutersj wrote:

If I understand correctly, this seems to be totally off-topic. You have something written in VHDL that has issues with delta cycles and you expect the synthesis tool to 'fix' this.

 

A number of options exist

  • ignore the unexpected synthesis result; garbage in/garbage out


You've put yourself in position where you cannot agree that the code I propose (the enums and conversion functions) is 100% legal and XST is limited to the clock skew (assignment) involving template (which is also legal). At the same time, it was demonstrated that the totally synthesis-distracting template is the sinsetivity-list-based standard proposed by you. So boy, who proposes the garbage to fix?


  • write a linter to intercept this kind of known bad stuff
  • write a VHDL preprocessor that automatically fixes this by using a single type for clocks such that intermediate conversions are not needed
  • do a 100% emulation of the VHDL language semantics by adding delta cycle convergence signals to your cores

  • The best way to do it IMHO is to let the user fix the VHDL code by simply using 1 type for global nets. Having a conceptual identical clock with delta cycles will sooner or later result in simulation misery and a skilled VHDL writer is aware of this issue and should be capable of compensating delta cycle mismatches (ever tried to run a gated clock over a chip?).

     



    The latter makes sense. But I created the topic to ask for a better solution, a XST-supported VHDL pattern. I consider it quite involving to mantain the CLK of outstanding type and I do not see any reason for it if synthesizers support VHDL that does provide all the necessary conversions. Finally, I do not think that everything you don't like is off-topic. Off-topic, IMO, are the "solutions" that do not address the issue posed in topic.
    Message Edited by v_tihhomirov on 01-26-2010 03:21 AM
    Message Edited by v_tihhomirov on 01-26-2010 07:54 AM
    0 Kudos
    Explorer
    Explorer
    6,384 Views
    Registered: ‎07-27-2009

    Re: Enumerated type clock

    Off-topic because you seem to be doing an emulator and post on a synthesis group?

     

    Anyway: you are totally right on everything! Your issue must be fixed now.

     

    Kind regards,

    Johan

    0 Kudos
    Teacher eilert
    Teacher
    6,363 Views
    Registered: ‎08-14-2007

    Re: Enumerated type clock

    Hi,

    it becomes more and more clear, that you are working on a very specialized and fundamental topic.

    In these groups you will mostly find practical oriented people who want to get their chips running, nothing more.

    So, don't be disappointed, when it comes to misunderstandings. We just have to work it out.

     

    But now back to your topic.

     you said "... introduces a delta-delay on clock line (clock skew)", which puzzles me a little.

    To me this statement is contradictory. Here's why:

      - Clock skew is a (measurable ! ) deviation in time of the rising clock edge of the same clock signal on different FF clock inputs.

      - Delta delays are a means to handle concurrent events in a sequential computing environment. Between any difference of delta cycles of the same event no time passes.

        However there might occur problems with the order of signal changes during these delta cycles. But then there's mostly something wrong with the modelling or the testbench.

     

    So, giving a computational artifact the name of a physical parameter may cause problems in understanding.

    ---

    Do you really mean "All(???) the code examples are given"?

    Sorry, but what you showed us was just a single FF, with alternative coding methods.

    To show skew effects, you need at least two FFs and a testbench that treats the clock and data lines to simulate these effects.

    And for synthesis you can simply forget anything that happens in delta delays (see above).

    Therefore you may have to deal with real signal skew on the silicon (not necessarily the clock nets) which you then can try to examine using post-par-simulations.

     

    Tell me, how many designs have you already made working on an real FPGA?

     

     

    ---

    Further you said: "... why multivalued signals might be necessary in HW are not comprehended easily in the HW design community."

    Well, they are, eg. when talking about FLASH memory cells. :-)

    But in the digital world with real chips the available hardware is just limited to '0','1' and 'Z' (on the outputs), so if you want to synthesize a multivalued signal you just need new silicon.

    Now, this surely isn't your approach since it would be too costly. :-)

     

    From the first paper you mentioned (the second papers link is empty)  I see that it's not about simple logic emulation, but fault emulation and BIST-techniques.

    So let's cite fom it:

    Encoded don’t-care value approach: An alternative
    solution for the problem is to rely on the encoded don’tcare
    value approach. It is based on coding the threevalued
    logic: 0, 1, X. To code these values we need two
    bits and thus, two instances of the emulating circuit. 0 is
    coded as (1,0), 1 as (0,1) and X as (0,0).

       

    Here we see introduced a three level logic (again not std_logic type compatible, since "don't care" is represented by '-' instead of the chosen 'X') similar to your approach.

    But these guys know, they have to code it with '0's and '1's, and build a hardware that works with these codes.

    So their multi-level-logic approach is a theoretical thing, while they are really working with multi-bit signals (better known to us as vectors).

    Correct me if I'm wrong here, but I suspect that you expect the tools to do the synthesis of the multi valued logic encoding for you. They don't!

     

    The original VHDL type bit consits only of '0' and '1'. 

    This has been expanded by the std_logic type quite soon.

    One goal was to make 'Z' synthesizable for tristate drivers.

    But the main goal was to expand simulation capabilities.

    With 'U' and 'X' you are able to see misbehavior in the simulations.

    With 'W', 'L' and 'H' you can e.g. handle pullups and such stuff. (You see, we are going slightly to analog stuff now)

     

    But all these values only work inside a simulation environment.

    Actual ordinary gates and FFs just have '0's and '1's and so there's no way to represent any multi valued logic with one of these.

    The conversion to multi-bit encoding has yet to be done by the designer, since this is a new idea which is useful only for a limited range of applications (like the one you intend).

     Maybe one time there will be a specialized synthesis package for this.

     

    Have a nice synthesis

      Eilert

     

    0 Kudos
    Explorer
    Explorer
    6,355 Views
    Registered: ‎04-16-2009

    Re: Enumerated type clock

    You're right that the clock skew demonstration requires at least two FFs. It is what I did creating the topic on comp.lang.vhdl (it is appropriate there because it is VHDL sim rather than XST problem).

     

    Nobody demands XST to support the multivalued silicon/conductors. You are right that bit vectors represent multivalued signals in digital chip. But, you omit the neat VHDL constructs that exist to specify them. These constructions are also on the title of this topic: enumerated types naturally result in multiple bits (with the exception of std_logic subtypes). Since this device eliminates the need to specify the multi-bit encoding explicitly and is a part of VHDL standard, no extra synthesis package is required. It must be so because Jonathan Bromley states: "In general, enumerated types in VHDL synthesise to hardware signals that have enough bits to provide a unique 1/0 binary value for each numeration literal.  So, for example, your "trit" data type with its three values 'U', '0', '1' will synthesise to at least two digital ignals (possibly three, if the tool chooses one-hot coding)." As a matter of fact, Altera's Quartus supports the enums very well. It is XST that has some porblems, which I report here. It is what needs to be fixed.

     

    Do not be confused by the purpose of my research. I could clarify that the emulator for plain fault-free sequential circuits demands the same 3rd (call it X, unknown) value as much as the fault emulator does and it does not matter that BIST or some another core is involved. Any project specializes in and involves something. I gave the links just to satisfy your curiosity on why sombody might need more-than-two values running in real HW and want to say that my proect isn't more special/theoretical than a 3-state automata plus a controller and ask you not to be intimidated. Despite of theoretic-academic interest, the thing must be synthesizable to be useful in practice. And there is no need to run a real FPGA to prove that design is operational since post-synthesis simulation suffices (speed/size report also makes the synthesis interesting).

     

    Thank you for at least trying to understand the issue.

    Message Edited by v_tihhomirov on 01-27-2010 05:52 AM
    0 Kudos