Clock Edge notation

[KJ]

On Sep 10, 9:56 am, Andy <jonesa...@comcast.net> wrote:

On Sep 8, 9:51 am, "KJ" <kkjenni...@sbcglobal.net> wrote:

snip
By "what we wanted", I meant that the subject of the thread, taken as
a whole, has to do with methods for optimally dealing with encodings
or conditions that are not by definition mutually exclusive, but are
functionally guaranteed to be so. A binary encoding is by definition
mutually exclusive, so starting with that would not demonstrate what
the thread, as a whole, seeks.
What 'the thread as a whole seeks' is to take an arbitrary collection

of signals, impart some supreme insight that this arbitrary collection
has some mutual exclusiveness property to it in some fashion OTHER
than coding it in that manner....and what I've been saying all along
(somewhat casually at first, a bit more forcefully in my Sept 7 post)
is that if you have some mutual exclusiveness than the functional code
(not the asserts) will directly support that by how it is coded...and
that means coding in a sum of products form or using an enumerated
type...period.

In light of the thread subject, a more useful demonstration (which you
were not asked for) would be to demonstrate a conversion from a one-
hot vector to a binary or enumeration encoding, and back, with minimal
(preferably zero) logic. As you have pointed out, that is likely not
possible.

I claimed that zero logic is not possible, 'minimal' would depend on

one's definition. The minimal way to do this is some form of the
simple sum of products formation (an example way of 8->3 encoding is
below)

Encoded_OneHotInps(0) <= OneHotInps(1) xor OneHotInps(3) xor
OneHotInps(5) xor OneHotInps(7);
Encoded_OneHotInps(1) <= OneHotInps(2) xor OneHotInps(3) xor
OneHotInps(6) xor OneHotInps(7);
Encoded_OneHotInps(2) <= OneHotInps(4) xor OneHotInps(5) xor
OneHotInps(6) xor OneHotInps(7);

Using the above encoding followed by a 3->8 decoder function results
(using Quartus) exactly one logic element per output for a total of
8.

where 'OneHotInps' is an 8 input supposedly one hot input vector,
'Encoded_OneHotInps' is a 3 bit vector that encodes the information.
Just for grins I used 'xor', 'or' could also have been used. I can't
prove that it is 'minimal' but I'll bet you can play all kinds of
games with 'xor', 'or' or changing the function around a bit and get
the exact same result in terms of logic resource usage.

The mechanism for telling the compiler about the 'one hot' nature of
the input is not through an assertion (as you claim) or through a new
language keyword (as Weng claims is required) but through the actual
functional logic that is written. Any other formulation in VHDL using
a case statement or an if statement(s) (without Weng's proposed
'orif') is doomed because it will inherently encode either a priority
encoding (i.e. if/elsif/elsif/endif) or dependency on inputs that, in
fact, declares that maybe, just maybe, the inputs are not one hot
(i.e. using a case statement where the cases are something like "0001"
when REALLY you would like to say "---1")

The sum of products formation (or the product of sums for the DeMorgan
fans) is likely the best one that truly encodes the one hot nature of
the input because it logically depends on those inputs being one hot
and will produce an incorrect coding if somehow two or more of those
puppies ever got set. It does this by including multiples of those
supposedly one hot inputs into single equations taking full advantage
of the higher knowledge that only one term should ever fire for all of
the terms that are being 'or' or 'xor' -ed together.

There was great debate on just what Weng's 'orif' would do in certain
circumstances, even to the extent that proper indenting and color
coding would be needed but the bottom line is that 'orif' would have
to synthesize down to a sum of products implementation. My point back
to Weng, that he never responded to either time, was that he was
claiming superior performance or resource utilization. I seriously
doubt that, and he was unable to demonstrate anything that was an
improvement over what I believe to be best practice (enumerated types
or vector coding for the 'unconstrained number of enumerations'
situation). At best, 'orif' is a clearer and more productive way of
coding...not convinced that it is, but that's what it amounts to.

By the way, another interesting way to encode the one hots could be
the following....
Encoded_OneHotInps_var := (others => '0');
for i in OneHotInps'range loop
Encoded_OneHotInps_var := Encoded_OneHotInps_var + to_unsigned(i *
to_integer(unsigned'("0" & OneHotInps(i))),
Encoded_OneHotInps_var'length);
end loop;

Functionally this produces the exact same result given one hot inputs
as the previous example using 'xor' or 'or'. But the synthesized
result is larger (14 logic cells in Quartus). While the above code
snippet treats each of the inputs as an independent thing and depends
on the inputs really being one hot in order to produce a correct
result (just like the 'xor' implementation). At the moment I don't
quite understand why it is sub-optimal to a simpler sum of products
(maybe it's just a Quartus thing)...but it is.

Several options have been proposed within the existing language and
tool capabilities, but they are all limited to either data types that
include a "don't care" value understood by synthesis,
Simulation doesn't really like the "don't care" either...witness your

use of "0001" as a case value instead of "---1" that you would really
have liked to say. But sim and synth both are treating them
appropriately per the language standard and the rules of boolean
logic.

or that support
an OR operation between values.
And what's wrong with that?

It is possible that an enum value
could be treated as a don't care if nothing is done in response to it,
but I have not tried that. Methods capable of dealing with
unconstrained dimensions of input and output would be required as
well.
The unconstrained (i.e. parameterizable) enumerated type is simply a

coded vector. The number of 'enumerations' would be 2**n. Your root
type in this case would be an 'n bit' vector which represents the
coding of the various possibilities.

Starting from unencoded form and trying to claim 'one hot-ness'
without realizing that there really is a coded form that underlies the
'one hot-ness' is the fallacy. Not explicitly defining this coded
type as the basis for the claims of 'one hot-ness' results in sub-
optimal (larger logic resource usage) implementations. Once coded in
that manner, synthesis needs no additional help telling it about the
'one hot-ness'....such help is about as useful as getting coding tips
from the boss.

Asserting such knowledge is fruitless because synthesis' job is to
implement the functional logic (not the asserts) correctly. At best
the assertion is true, and therefore redundant since the functional
logic defines the same thing that is being described by the
assertion. At worst, the assertion is not always true and you don't
have a formal logic checker to find that out

KJ

 

[Andy]

On Sep 10, 1:08 pm, KJ <Kevin.Jenni...@Unisys.com> wrote:

KJ,

What happens if the VHDL description does not fully define the
behavior?

I could say that you're at the mercy of how the synthesis tool wants
to generate it...but in reality, by definition, synthesis (and
simulation) assume that the logic description is complete. If it's
incomplete the simulator can help you find it, just like it can help
you find any other design flaw. But synthesis is supposed to
implement it, if you have a design flaw in your logic that's not it's
concern.

No, neither assumes the description is complete. Both abide by the
entire description (executable and declarative sections), logically
complete or not.

Synthesis does implement the described behavior, you and I just have a
disagreement over just what constitutes the described behavior.

Let's look at the following example:

signal count, output : integer range 0 to 511;
...
process (rst, clk) is
begin
if rst = '1' then
count <= 0;
output <= 0;
elsif rising_edge(clk) then
if restart = '1' then
output <= count;
count <= 0;
else
count <= count + 1;
end if;
end if;
end process;

The restart input above is externally guaranteed to be set at least
once every 500 clocks. If it is not, then an error has occurred
somewhere else, and we don't have to handle it or recover from it
without external assistance.

OK...you're declaring this to be the case.



The question is what should the hardware do if count is 511, and
restart is not set? The logic description does not say what happens to
count

Sure it does...it says to add 1. No place in your code do you say to
not count if the count gets to 511.

Partial credit: It says to add one to count, but "signal count,
output : integer range 0 to 511;" also says "don't store anything less
than 0 or more than 511 in count or output.

It can add 1 to the count all day, but it cannot store the result back
in count unless it is in range. This is a vital difference.

You want to be bound by only the executable statements, but the
language (and the total description) includes the declarations and
their limitations.

Do not confuse "vector math" with "integer math". Vector math rolls
over, integer math does not.

, because the executable model stops, per the language
specification.

No, the simulator stops...

Should the hardware model stop too?

Why should it? Just because the simulator stops does not imply that
the synthesized form should as well. You're going back again to your
claim that synthesis implements what is simulatable whereas in fact
synthesis and simulation are two totally different tools do two
totally different thing that are supposed to conform to the same
language specification...nowhere does anyone claim that different
tools should conform to some other tool.

Or should the
synthesis tool interpret the situation as a "don't care"?

No, it should do what you said and attempt to add 1....like it clearly
says to do. The fact that it is unable to produce '512' is your
design issue to resolve, not the synthesis tools problem.

So what you just said is that synthesis needs to make count big enough
to store 512? How big should it be? 1024? 2048?

It is not a design issue, I accounted for it in the built-in
assertion.

The language cannot store the 512 back into count. That is undefined
per the LRM.

If what you say was true (it should just add 1), then the following
code would synthesize the same way whether count was integer range 0
to 511, or unsigned(8 downto 0):

if count - 1 < 0 then
count <= 511; -- or (others => '1')
output <= '1';
else
count <= count - 1;
output <= '0';
end if;

But if count is an unsigned(8 downto 0), then the condition is by
definition false (unsigned subtraction returns unsigned), and output
never gets set.

If OTOH, count is an integer range 0 to 511, then the condition has
meaning (because integer operations are not limited to the ranges of
their operands), and output will be asserted when the counter is set
to zero (which would be optimized to a rollover).

This example proves that "count - 1" does not always mean the same
thing, depending on what the data type is.

I can do the same thing with an up counter:

if count + 1 > 511 then
output <= '1';
count <= 0; -- or (others => '0');
else
output <= '0';
count <= count + 1;
end if;

With unsigned(8 downto 0), output will never get set, because the
maximum value for the result of the operation is still 511. So count +
1 is not the same thing either: adding one to an integer is never
DEFINED as a rollover; however, the storage may be optimized to effect
a rollover.

By your understanding, the "definition" of "count <= count + 1" should
be the same no matter what data type is used, but in fact, there are
differences caused by declarations and their effects (built in
assertions, operator definitions, etc.).

There's more to the logic description than just the "executable part".

Andy

 

[Weng Tianxiang]

On Sep 10, 2:01 pm, "John_H" <newsgr...@johnhandwork.com> wrote:

"Weng Tianxiang" <wtx...@gmail.com> wrote in message

news:1189440628.616782.132240@o80g2000hse.googlegroups.com...

Hi,
I would like to know what is the name of Altera latest and most
advanced chip serial that is competable in technology with Xilinx
Vertex V in terms of system strucute(LUT6..., not 65nm).

Thank you.

Weng

You won't have an identical mapping between manufacturers.

The Altera Stratix-II, Stratix-III, and Arria GX families should all
implement their ALM structures which can provide full LUT6 results in a
structure shared between two registers. The Xilinx LUT6 is per-register for
the Virtex-5. Your serial speed or specific interface requirements may
eliminate the Arria GX from consideration, but this very new family is
cheaper for production than the more flexible Stratix series devices.

Do a little reading on the Altera families and get to know them on your own.
It could be that your needs don't map to our assumptions on what you really
need. The family overviews shouldn't take a significant amount of your
time. FAEs may also provide you with pertinent data.

- John_H

Hi John_H,
Based on your suggestion I thought it is Stratix-III I want.

"Your serial speed or specific interface requirements may
eliminate Arria GX from consideration, but this very new family is
cheaper for production than the more flexible Stratix series devices."

Thank you very much.

Weng

 

[KJ]

"Andy" <jonesandy@comcast.net> wrote in message
news:1189465697.930656.118600@o80g2000hse.googlegroups.com...

On Sep 10, 1:08 pm, KJ <Kevin.Jenni...@Unisys.com> wrote:
KJ,

What happens if the VHDL description does not fully define the
behavior?

I could say that you're at the mercy of how the synthesis tool wants
to generate it...but in reality, by definition, synthesis (and
simulation) assume that the logic description is complete. If it's
incomplete the simulator can help you find it, just like it can help
you find any other design flaw. But synthesis is supposed to
implement it, if you have a design flaw in your logic that's not it's
concern.

No, neither assumes the description is complete.
Yes they do...simulators simulate the logical description code that is

written, synthesis tools synthesize the logical description code that is
written. Neither grabs for anything beyond the written code to complete
it's task...it is assumed by both tools to be logically complete. Whether
or not it is what you want or has some other logic flaw is your problem to
figure out. If you choose to use a formal logic checker to have it look for
logical discrepancies between what you've written in the logical description
and your assertions is up to you, maybe it will help you find your design
errors.

Both abide by the
entire description (executable and declarative sections), logically
complete or not.
No, synthesis does not look at assertions except (possibly) for ones that

are statically determinate. You keep claiming this but do not back it up in
any way. Name one synthesis tool and post one design that gets synthesized
one way when there are no assertions but synthesizes to something different
with the inclusion of a single assert. Post it up here for all to see.

Your previous post on this thread in regards to the 0-511 counter example
said...

every synthesis tool I know of already implements a
rollover, which, while optimal from a resource POV, is not described
anywhere in the "logic description".
If that is the case, then every synthesis tool that you know of is not

compliant with the LRM so surely you've opened a service request to them on
this, right? If not, why not? Or isn't it just remotely possible, that
you're incorrect and that a failed assertion is a design or modelling error
on the part of the person who wrote the code and is NOT the fault of any
tool because it failed to detect your flawed logic.

Synthesis does implement the described behavior, you and I just have a
disagreement over just what constitutes the described behavior.

Well we certainly do agree on that point.

Let's look at the following example:

signal count, output : integer range 0 to 511;
...
process (rst, clk) is
begin
if rst = '1' then
count <= 0;
output <= 0;
elsif rising_edge(clk) then
if restart = '1' then
output <= count;
count <= 0;
else
count <= count + 1;
end if;
end if;
end process;

snip
The question is what should the hardware do if count is 511, and
restart is not set? The logic description does not say what happens to
count

Sure it does...it says to add 1. No place in your code do you say to
not count if the count gets to 511.

Partial credit: It says to add one to count, but "signal count,
output : integer range 0 to 511;" also says "don't store anything less
than 0 or more than 511 in count or output.
integer range 0 to 511 does not say anything about storing or not storing

any result that is outside the declared range. What it says is that YOU are
guaranteeing that no matter how this code is used, that YOU will make sure
that count stays in the proper range. It is your responsibility to make
sure that happens, it is synthesis' responsibility to generate hardware that
implements the stated function it's only use for "integer range 0 to 511" is
to allow it to set aside enough storage space to represent an integer in
that range. It will not implement anything to "don't store anything less
than 0 or more than 511 in count" as you've stated...you're way off on that
one.

Synthesis doesn't care that you have failed to provide adequate storage. It
is YOU that have misused the device since...
- You declared count to be in the range from 0 to 511
- You used the synthesized hardware in a manner that allowed it to try to
operate outside that range.
- You provided no mechanism in the logical description to guarantee that, no
matter how the hardware is operated, that count would remain in the range
that YOU defined.

It can add 1 to the count all day, but it cannot store the result back
in count unless it is in range. This is a vital difference.

Kind of conflicts with your earlier statement that every synthesis tool you

know WILL store it back in count by rolling it over. The result does get
stored, the fact that the result is wrong is a design/usage flaw on your
part. Are you now saying that every synthesis tool is wrong for storing
your specified result incorrectly?

You want to be bound by only the executable statements, but the
language (and the total description) includes the declarations and
their limitations.
Simulators simulate just fine and the synthesis tools synthesize just fine

when there is only the logical description and no asserts.

On the other hand, simulators have nothing to simulate and synthesis tools
will synthesize nothing when you have no logical description but only
asserts.

If what you claim held any nugget of truth to it at all, both sets of code
would perform in the same manner....but they don't...at least not in VHDL
now do they? That's because the asserts play absolutely no role in
determining how a signal should change (for a simulator) or the boolean
logic that needs to be implemented (for a synthesizer).

Take this example
c <= a and b;
assert ((a or b) = c)
report "OOPS!"
severity ERROR;

Run it through any synthesis tool and it will produce a bitstream that
implements "c <= a and b". Yet according to you there is an obvious paradox
here in that I've asserted that c should be equal to "a or b". Following
your logic no synthesis tool in the world should be able to complete it's
task because of the logical conflict between the logical description and the
assertion. The reason it synthesizes is because there is no paradox, the
synthesis tool looks ONLY at the logical description, not the assertions.
But feel free to take this code and run it through any synthesis tool and
then open a service request to the supplier on their supposedly deficient
tool. Post the replies you get up here so we can all learn.

Now take the above code into any simulator, do a "run -all" and it will run
just fine, no assertion will be hit....but Doooooh, that's because we need a
testbench to generate stimulus for it huh? Because 'U' and 'U' (the logic)
DOES happen to equal 'U or "U' (the assert). So add the following testbench
code and run again
a <= '1';
b <= '1';
Dooooooh, the simulator ran AGAIN without failing the assertion. So I guess
we'll need to open service requests to all the simulator vendors for not
catching this too? Simulators do NOT validate that the assert statement is
logically correct. All a simulator does with an assert is check that the
condition is true for any inputs that you just happen to throw at it. If
not, then it throws an exception. Don't give it the right conditions and
the assert will never fail. In fact, in cases like this the simulator
doesn't even have to 'stop'.

I can tell the simulator to only stop on 'FAILURE' level severity in which
case it will run to completion again....Dooooooh. I shudder to think what
you think the synthesis tool should do as a function of severity level on
the assert.

Now take the original code and run it through a formal logic checker. Here
I'll take a guess since I've never used such a tool but I'll bet that it
would come back and say something like...
"Your logic does not correctly handle the case when a=1, b=0 but you've
asserted that the result should be 1"
"Your logic does not correctly handle the case when a=0, b=1 but you've
asserted that the result should be 1"

, because the executable model stops, per the language
specification.
Not always, see above example. It will only stop if given the proper input.

It is not a formal logic checker.

No, the simulator stops...

Should the hardware model stop too?

snip
Or should the
synthesis tool interpret the situation as a "don't care"?

No, it should do what you said and attempt to add 1....like it clearly
says to do. The fact that it is unable to produce '512' is your
design issue to resolve, not the synthesis tools problem.

So what you just said is that synthesis needs to make count big enough
to store 512? How big should it be? 1024? 2048?

No, YOU told it that 9 bits would be enough by declaring that YOU would
guarantee that count would never stray from the range of 0 to 511. Surely
you don't expect the synthesized result to be correct when operated outside
of the specified range do you? Do you also expect a 3.3V part to work when
connected to a 24V supply? Both cases indicate usage outside of the
specified range, so don't expect things to 'work'.

It is not a design issue, I accounted for it in the built-in
assertion.

It's not a design issue that you let a counter get out of the range that YOU

defined??!! You have a very misguided view of what assertions do and don't
do.

The language cannot store the 512 back into count. That is undefined
per the LRM.
OK, so your previous statement is that this is not a design issue on your

part because of the built-in assertion and now you (correctly) say that a
count of 512 can not be stored back into count without violating the
LRM....so you've written code that under certain conditions is not compliant
to the VHDL LRM and you do not consider this to be a design issue on your
part???? Amazing.

If what you say was true (it should just add 1), then the following
code
SNIP

No more examples please.....nearly everything you've had to say on this
thread has been incorrect, why compound it further? Suffice it to say that
for your examples that the rules for '+' and '-' are different for unsigned
than they are for integers...and all of that behaviour is properly defined
in the LRM or the IEEE numeric_std package. Use the tools properly and they
will do what you intend, misuse them and they will bite you.

KJ

 

[Jonathan Bromley]

hi Kevin and Andy,

I don't want to get involved in the fisticuffs
but I honestly think Kevin is missing precisely the
point of the original (way, way back original)
discussion, which is that new language features
can provide a form of assertion that can be both
tested in simulation and exploited in synthesis.

[KJ]

No, synthesis does not look at assertions except (possibly) for ones that
are statically determinate.

Agreed, for current VHDL tools.

You keep claiming this but do not back it up in
any way. Name one synthesis tool and post one design that gets synthesized
one way when there are no assertions but synthesizes to something different
with the inclusion of a single assert. Post it up here for all to see.

Here it is: in SystemVerilog, because it's the only
way I can do it, and with the very important caveat
that this is NOT the only way to achieve the desired effect.
The point is, though, that it works, and it precisely
illustrates the idea that Andy and I have been trying
to elucidate.

module onehot_to_binary (
( input logic [3:0] onehot_vector
, output logic [1:0] binary_code
);

always @(onehot_vector)
unique if (onehot_vector[3])
binary_code = 3;
else if (onehot_vector[2])
binary_code = 2;
else if (onehot_vector[1])
binary_code = 1;
else if (onehot_vector[0])
binary_code = 0;

endmodule

The "unique" prefix to "if" is, for simulation, an
assertion that exactly one branch of the "if" is
accessible. At runtime in simulation, *all*
branch conditions of the "if...else if" are evaluated
at the outset, and the simulator checks (asserts)
that exactly one of those expressions is true. If
not, it throws a runtime error.

Synthesis knows that this is the semantics of "unique if",
and therefore knows that it can create logic that gives
the right answers if exactly one branch's condition is true,
but if more than one branch were true, the logic would not
match the if statement's behaviour in the absence of "unique".
The assertion also permits the synthesis tool to assume that
assignment to the output is complete - every branch of the
if makes an assignment to "binary_code", and we know
by assertion that precisely one branch will be executed -
so it is unnecessary and inappropriate to add the latches
that would be needed in the absence of "unique".
You can see this working today in at least two synth tools and
at least two simulators. In synthesis, there is a real
saving of gates because the whole thing collapses to a
bunch of ORs. (Yes, I know that in an FPGA each output bit
would be a 4-input LUT function anyway, whatever the logic,
but that would no longer be true if there were more input
bits or if there were some downstream combinational logic.)

Yes, I know it's not an assertion in the conventional syntax,
but it is PRECISELY an assertion in simulation; an assertion
dressed-up in syntax that can reliably be handled by synthesis.

This is PRECISELY the problem that Weng's "orif" aims to
solve in VHDL.

There are serious limitations and difficulties both in
SystemVerilog's approach and in Weng's, but that doesn't
mean that KJ can dismiss them as meaningless or useless.
--
Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[Andy]

KJ,

I understand that you prefer to code the implementation explicitly,
and not rely on anything else to optimize it. That's fine; you and
others have aptly demonstrated how this problem can be coded
explicitly and implemented efficiently within the existing tools and
language standard. For many of the rest of us, interested in using
higher levels of abstraction in synthesis, we would prefer a method to
do so, and have identified a couple of potential solutions to that
end.

And there are other types of problems (e.g. synthesis of 'others' in
enumerated type state machines) for which most of use would also like
solutions (that already exist if you code at a low enough level). But
that's the whole point: what can we do to handle common problems
encountered while coding at higher levels of abstraction? We do not
want to do anything that would limit someone from coding at a lower,
more explicit level, but by the same token, we do not want to be
limited from coding at a higher level with similar efficiency (if
possible/practical).

I value your contributions to these discussions, and to the art of
VHDL in general, so I wanted to tone this down a bit...

Please accept my sincere apologies if anything I have said has
offended or mis-characterized you in any way; it certainly was not my
rational intent.

Andy

 

[KJ]

On Sep 11, 8:41 am, Jonathan Bromley <jonathan.brom...@MYCOMPANY.com>
wrote:

hi Kevin and Andy,

I don't want to get involved in the fisticuffs
but I honestly think Kevin is missing precisely the
point of the original (way, way back original)
discussion
Ummm...to be fair though Jon, while I do keep the point of the

original post in mind, threads take on sub-topics and go off on
various tangents and when I reply to something I generally keep the
text from the post so it is clear to what I'm referring to so I
wouldn't be reffering to something 'way, way back' that wasn't in the
post to which I'm replying. The tangent that Andy and I were off on
had to do with claims that he was making regarding assertions in the
current language standard that I feel are incorrect.

I presented my reasoning and provided examples demonstrating what I
see, Andy has presented his reasoning and has not provided any
examples that I haven't then shown to be false. If you feel you can
answer my specific objections then please do...but I'm guessing this
whole thread is dragging on all of us now, so this will be my last one
on the subject.

, which is that new language features
can provide a form of assertion that can be both
tested in simulation and exploited in synthesis.
Exploited in synthesis compared to what though is the rub. But that's

been beaten to death here.

[KJ]

No, synthesis does not look at assertions except (possibly) for ones that
are statically determinate.

Agreed, for current VHDL tools.

Then it would appear that you and Andy do not agree on the role of

asserts in synthesis either.

You keep claiming this but do not back it up in
any way. Name one synthesis tool and post one design that gets synthesized
one way when there are no assertions but synthesizes to something different
with the inclusion of a single assert. Post it up here for all to see.

Here it is: in SystemVerilog, because it's the only
way I can do it, and with the very important caveat
that this is NOT the only way to achieve the desired effect.
The point is, though, that it works, and it precisely
illustrates the idea that Andy and I have been trying
to elucidate.

Good play, man. I DID forget to say that I wanted a VHDL example now

didn't I?

<snip>

The "unique" prefix to "if" is, for simulation, an
assertion that exactly one branch of the "if" is
accessible. At runtime in simulation, *all*
branch conditions of the "if...else if" are evaluated
at the outset, and the simulator checks (asserts)
that exactly one of those expressions is true. If
not, it throws a runtime error.

Synthesis knows that this is the semantics of "unique if",
and therefore knows that it can create logic that gives
the right answers if exactly one branch's condition is true,
but if more than one branch were true, the logic would not
match the if statement's behaviour in the absence of "unique".
The assertion also permits the synthesis tool to assume that
assignment to the output is complete - every branch of the
if makes an assignment to "binary_code", and we know
by assertion that precisely one branch will be executed -
so it is unnecessary and inappropriate to add the latches
that would be needed in the absence of "unique".
You can see this working today in at least two synth tools and
at least two simulators. In synthesis, there is a real
saving of gates because the whole thing collapses to a
bunch of ORs.
Savings compared to what? Compared to using a priority encoding if/

elsif/endif...which by inspection does not encode the one-hotness? Or
savings compared to the simple forms that I've shown? I'm guessing
it's the former, not the latter.

This is PRECISELY the problem that Weng's "orif" aims to
solve in VHDL.

And if you read my postings, the only real objection I really had to

Weng's "orif" was his claims of improved performance. It's easy to
improve performance over an incorrect 'other' solution. You would
also note that I said what he might be able to claim 'orif' is
possibly a productivity improvement over commonly misused forms(i.e.
designer productivity in working lines of code per unit of time).

There are serious limitations and difficulties both in
SystemVerilog's approach and in Weng's, but that doesn't
mean that KJ can dismiss them as meaningless or useless.
I don't recall saying things to Weng that would be interpreted in that

manner, apologies to him if they were taken in that manner. I was
trying to get information on the basis for what appears to be
unsubstantiated claims.

KJ

Jonathan Bromley, Consultant

DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services

Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.brom...@MYCOMPANY.comhttp://www.MYCOMPANY.com

The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.

 

[KJ]

On Sep 11, 10:15 am, Andy <jonesa...@comcast.net> wrote:

KJ,

I understand that you prefer to code the implementation explicitly,
and not rely on anything else to optimize it.
Not at all, I routinely use all of the 'higher level' stuff...and have

the history of service requests to the synthesis tool suppliers to
prove it. I insist on logical correctness and clarity of code and
using the wrong tool (if/elsif/endif or case) to handle a one hot is
logically incorrect in my opinion....and I've demonstrated how
handling it properly with vector coding and enumerated types works
quite well...I rely on the synthesis tool to do it's job but I don't
expect it to clean up any mess of my own doing.

That's fine; you and
others have aptly demonstrated how this problem can be coded
explicitly and implemented efficiently within the existing tools and
language standard. For many of the rest of us, interested in using
higher levels of abstraction in synthesis, we would prefer a method to
do so, and have identified a couple of potential solutions to that
end.

You make me sound like an outcast. In the one hot case, the higher

level of abstraction is the enumerated type or coded vector...use it,
it's free.

And there are other types of problems (e.g. synthesis of 'others' in
enumerated type state machines) for which most of use would also like
solutions (that already exist if you code at a low enough level). But
that's the whole point: what can we do to handle common problems
encountered while coding at higher levels of abstraction?
I don't think Weng's 'orif' was an example of any higher level of

abstraction. It was an example of a possible designer productivity
improvement.

We do not
want to do anything that would limit someone from coding at a lower,
more explicit level, but by the same token, we do not want to be
limited from coding at a higher level with similar efficiency (if
possible/practical).
I agree, but you're elevating use of an 'if' statement as a solution

as being some higher level abstraction...it's not.

I value your contributions to these discussions, and to the art of
VHDL in general, so I wanted to tone this down a bit...

OK...I'm done with this thread.

Please accept my sincere apologies if anything I have said has
offended or mis-characterized you in any way; it certainly was not my
rational intent.
Wasn't taken that way....and apologies to you if my rebuttals to your

points were taken in any negative way also.

Kevin Jennings

 

[Mike Treseler]

Jonathan Bromley wrote:

The "unique" prefix to "if" is, for simulation, an
assertion that exactly one branch of the "if" is
accessible. At runtime in simulation, *all*
branch conditions of the "if...else if" are evaluated
at the outset, and the simulator checks (asserts)
that exactly one of those expressions is true. If
not, it throws a runtime error.

I like the idea that a "unique" keyword
in vhdl might eliminate the need
to deal with '-' characters while capturing
exactly the same design intent.

If such a keyword were added to vhdl,
there would be two ways to handle don't cares,
as you have pointed out. However there would also be
a non-trivial gain in code clarity,
and a new way for the computer to do
a bit more of the heavy lifting.

Having said that, we have probably already spent
enough time on this thread to pay for enough luts
to convert all '-' bits to '0'
for the next ten years

-- Mike Treseler

 

Since a minimal state machine is one Flip Flop with pheraps spme gates, then the largest number of state
machines possible is equal to the number of FF's that can be implemeted within a chip.

 

[John Retta]

From an engineering point of view having tools which run
under Linux is preferred. I am a command line, shell person ...
not a Windows drag-drop ... double click kind of user.

However, two factors have been influential. It has been only
in the last two years (I think this is correct), that the Xilinx tool
set have run natively under Linux, and the price difference between
Modelsim PE vs LE was almost 3:1 when I had it quoted a
few years ago. Kicker was that there was no performance
increase in LE .... just the ability to run under Linux.

Anyway, as a one person show, keeping tool cost low
is a premium.

Anyway, I bought a laptop 4 weeks ago ... it had Vista
Home edition on it ... and I thought I would give it a try.
Keep installing EDA tools, and utilities until I found a show stopper.
Well I surprisingly did not. Modelsim PE and webpack, as well
as Quartus ran without problem. In terms of performance
improvement of XP vs Vista, hard to tell since I did not
benchmark same hw with different OS, but I suspect there
is none
--
Regards,
John Retta
Owner and Designer
Retta Technical Consulting Inc.
Colorado Based Xilinx Consultant

email : jretta@rtc-inc.com
web : www.rtc-inc.com


"Paul Floyd" <root@127.0.0.1> wrote in message
news:slrnfft6m7.iu.root@tryfan.netpratique.fr...

On Sat, 29 Sep 2007 03:51:43 -0700, prince@dyumnin.com
prince@dyumnin.com> wrote:
On Sep 22, 10:49 pm, "John Retta" <jre...@rtc-inc.com> wrote:
I bought a laptop with Microsoft Vista Home,
installed Modelsim PE 6.3a , and ran without
problem.
In your experience would you recommend running EDA Tools under Vista?
Or would you recommend XP/Linux?

Personally, my order of preference is Solaris, Linux, HP-UX, Windows.

You can't have it all. Solaris SPARC has poor price/performance these
days. Solaris x86/64 isn't very well supported. Linux, well, google for
'OOM kiler' and decide for yourself if you prefer unconditional
stability or a bit of speed. Does anyone use Windows for serious
simulation? (I ask that as a developer that's worked on field-solver
based parasitic extraction and mixed signal simulation).

A bientot
Paul
(Not speaking for Mentor Graphics)

 

[Kai Harrekilde-Petersen]

"John Retta" <jretta@rtc-inc.com> writes:

From an engineering point of view having tools which run
under Linux is preferred. I am a command line, shell person ...
not a Windows drag-drop ... double click kind of user.

However, two factors have been influential. It has been only
in the last two years (I think this is correct), that the Xilinx tool
set have run natively under Linux, and the price difference between
Modelsim PE vs LE was almost 3:1 when I had it quoted a
few years ago. Kicker was that there was no performance
increase in LE .... just the ability to run under Linux.

I was quoted a 1:2.75 ratio between PE and SE last year - SE is
available under both Linux and XP.

However, the SE version includes a number of options that must be
licensed separately with PE.


Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

 

[Mike Treseler]

John Retta wrote:

It has been only
in the last two years (I think this is correct), that the Xilinx tool
set have run natively under Linux, and the price difference between
Modelsim PE vs LE was almost 3:1 when I had it quoted a
few years ago. Kicker was that there was no performance
increase in LE .... just the ability to run under Linux.

For what it's worth,
I have found that running SE on Linux
is significantly faster than using the
same SE license for a windows session on the
same machine.

-- Mike Treseler

 

[Allan Herriman]

On Sun, 30 Sep 2007 09:25:00 -0700, Mike Treseler
<mike_treseler@comcast.net> wrote:

John Retta wrote:

It has been only
in the last two years (I think this is correct), that the Xilinx tool
set have run natively under Linux, and the price difference between
Modelsim PE vs LE was almost 3:1 when I had it quoted a
few years ago. Kicker was that there was no performance
increase in LE .... just the ability to run under Linux.

For what it's worth,
I have found that running SE on Linux
is significantly faster than using the
same SE license for a windows session on the
same machine.

Hi Mike,

Would you care to speculate why?

Thanks,
Allan

 

[Mike Treseler]

Allan Herriman wrote:

Hi Mike,

Would you care to speculate why?

Pure speculation:
Perhaps because modelsim was first developed
on unix systems and so has tighter memory interfaces
on linux than on a windows port.

-- Mike Treseler

 

[HT-Lab]

"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:5ma0u7FceejpU1@mid.individual.net...

John Retta wrote:

For what it's worth,
I have found that running SE on Linux
is significantly faster than using the
same SE license for a windows session on the
same machine.

-- Mike Treseler

I can confirm Mike's finding, I have done the same test and found that SE
under Linux (64bits Gentoo) was about 5% faster than SE under Win2K. I used
my AES core as a testcase. As usual YMMV and "lies, damn lies and
benchmarks" applies. What is definitely true is that vcom is much faster on
Linux than on Windows which I believe is due to the caching filesystem on
Linux whereas Windows uses write-through?

Hans
www.ht-lab.com

 

[Kai Harrekilde-Petersen]

Mike Treseler <mike_treseler@comcast.net> writes:

Allan Herriman wrote:

Hi Mike,

Would you care to speculate why?

Pure speculation:
Perhaps because modelsim was first developed
on unix systems and so has tighter memory interfaces
on linux than on a windows port.

Are you sure that modelsim was first developed on unix? - I recall
Modelsim for Windows 3.11 fitting on a single 1.44MB floppy back in
around '92.

Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk>

 

[HT-Lab]

"Kai Harrekilde-Petersen" <khp@harrekilde.dk> wrote in message
news:u7im5i640.fsf@harrekilde.dk...

Mike Treseler <mike_treseler@comcast.net> writes:

Allan Herriman wrote:

Hi Mike,

Would you care to speculate why?

Pure speculation:
Perhaps because modelsim was first developed
on unix systems and so has tighter memory interfaces
on linux than on a windows port.

Are you sure that modelsim was first developed on unix? - I recall
Modelsim for Windows 3.11 fitting on a single 1.44MB floppy back in
around '92.

The first (VHDL only) version was developed on DOS and written by two very
clever chaps in the US, one was Bob Hunter and the other was Walter Vines.

Hans
www.ht-lab.com

Kai
--
Kai Harrekilde-Petersen <khp(at)harrekilde(dot)dk

 

I think the MI5 man is closer to the topic.


On Sun, 2 Dec 2007 04:48:00 -0800 (PST),
Andrew.Adler.group.com@gmail.com wrote:

.:: Unix and Linux Hacking and Security ::.
1. Unix - Vulnerabilities and Advisories
-- Tutorials and Papers
-- Specific Exploits and Vulnerabilities

2. Unix - Security Tools
-- Unix Security and Audit Tools (Including IDS and Access Control
Tools)
-- Unix Log Analysis Tools
-- Unix Proxies, Firewalls and Accessories
-- Unix Miscellany

3. Unix - BSD, FreeBSD, etc...
-- FreeBSD
-- BSD and Misc. BSD variants
-- BSD Security Tools
-- BSD Micro-distributions

4. Unix - Solaris, SunOS etc...
-- Solaris
-- SunOS
-- Cobalt Appliances
-- SunOS and Solaris Security Tools

5. Unix - Other Flavors (Irix, HPUX, AIX, etc...)
-- SGI/Irix
-- HP-UX
-- AIX
-- SCO
-- Miscellaneous

6. Linux - Vulnerabilities and Advisories
-- Linux - General Hacking
-- Linux Application Exploits
-- Linux - Red Hat Specific
-- Linux - Debian Specific

7. Linux - Security Tools
-- Linux - Intrusion Detection
-- Linux - Access Control
-- Linux Log Analysis Tools
-- Linux Rootkits
-- Linux Proxies and Firewalls
-- Linux - General Security and Audit Tools

8. Linux - Security-oriented mini- and micro-distributions
-- DMZS-Biatchux
-- NSA Security Enhanced Linux
-- Linux Mini- and Micro-distributions
-- Applications

.:: Windows Hacking and Security ::.
1. Windows Vulnerabilities, Advisories, and even security flaws
introduced by so-called security products!!!
-- Microsoft IIS Vulnerabilities
-- Microsoft FrontPage Vulnerabilities
-- Microsoft Internet Explorer Vulnerabilities
-- Windows Application Vulnerabilities
-- Windows Internet/Networking Vulnerabilities
-- Insecurities introduced by "security" programs!
-- Netscape Browsers
-- Windows Hacks - Miscellaneous

2. Windows Security and Auditing Tools
-- Windows Registry Tools
-- Windows and MSDOS Security and Auditing Tools
-- Windows Local Security
-- File/Disk/Log Shredders

3. Windows Miscellany
-- Raw Sockets and Custom Packet Building
-- A Few Little Extras for Microsoft "Fans"

.:: Crypto, Virology, Cracking and Backdoors ::.
1. Cryptography, Cryptanalysis, Steganography
-- Crypto: PGP and GPG
-- Crypto: Cryptanalysis
-- Crypto: Steganography
-- Crypto: Miscellaneous
-- Misc. File Encryptors

2. About Viruses and Worms
-- Virus Info Files and Advisories
-- Worms
-- Virus/Worm Protection Utilities

3. Backdoors, Trojans and defenses
-- Back Orifice and BO2K
-- SubSeven and Addons
-- Other Remote Administration Tools
-- Trojan Detectors/Removers/Retaliators
-- Information Files

.:: Learn what Hackers know, how they do it, and what you can do to
keep your system safe ::.
1. General Hacking Information
-- General Security Concepts
-- Antique Systems
-- Oracle
-- Tools, Advisories and Exploits affecting multiple platforms
-- PC Software and BIOS Hacking
-- Truly Miscellaneous Hacking Info

2. Password Security
-- Password Hacking
-- Password Generators
-- Password Security Audit Programs
-- Word Lists

3. Scanning, Fingerprinting and similar techniques
-- Network Scanning
-- "Wargames" Modem Carrier Scanning
-- Fingerprinting
-- Sniffing

4. How Hackers Attack Numerous Internet Services
-- Denial of Service Attacks
-- Email and News
-- Proxies and IP Spoofing
-- DNS and BIND
-- SPAM
-- FTP
-- General Unsorted Information
-- Indispensible Internet Utilities
-- Cable and DSL Info and Hacking

5. How Hackers Attack Web Servers, CGIs, PHP, ASP, etc...
-- Web Site Hacking - General and Miscellaneous
-- Web Site Hacking - Specific Sites
-- Web Site Hacking - Servers
-- Web Site Hacking - CGI, Perl, ASP, PHP etc.
-- Web BBSes
-- Web Site Hacking - Audit Tools

6. How Hackers attack IRC, Instant Messaging, and Multiplayer Games
-- ICQ Hacking
-- IRC Hacking, Scripts and Bots
-- AOL Instant Messenger (AIM)
-- Miscellaneous Chat/gaming Systems

7. Vulnerabilities found in Platforms with Smaller Market Share
-- Macintosh
-- PalmOS
-- Printers
-- Dedicated Network Appliances, Hubs, Routers, etc...
-- Cisco Equipment
-- Miscellaneous

8. How Hackers Attack Novell and 802.11b Networks
-- Novell Networks
-- Wireless LANs
-- X.25 Networks
-- Miscellaneous Networking Information

.:: Computer Security Information ::.
-- Access Control
-- Basics
-- Chat Systems
-- Cryptography
-- Denial Of Service
-- Hacking Security Groups
-- Hardening Securing Papers
-- ICQ
-- Intrusion Detection Systems
-- IRC
-- Miscellaneous
-- Network Auditing Secuirty Penetration
-- Online Privacy
-- Operating Systems
-- Protocols

.:: Phreaking - The black art of telephony ::.
1. GENERAL - General Information About the Phone Company
-- Hacking Answering Machines and Voice Mail
-- Phreaking Programs

2. Electronic Toll Fraud and Other Phone Devices
-- The Fixer's Box Review - Read this before you read the rest of
these files!
-- Blue and Green Boxes
-- Red Box
-- Beige and Bridge Boxes
-- Various new boxes
-- Programs to generate phreak tones

3. All about Payphones, COCOTs, BOCOTs, etc...
-- Payphones
-- COCOTs
-- Nortel/Quortech Millennium
-- Smart Cards/Phone Cards

4. Cellular Telephones and the Hacking Thereof
-- Cellular Phones by Manufacturer
-- Miscellaneous Info
-- Miscellaneous Utilities

5. Caller ID and ANI
-- Caller ID and CLASS
-- ANI and ANAC

6. Scans, numbers of interest
-- Lists of Phone Numbers

7. Sounds from the phone system
-- SIT Tones are said to thwart predictive dialers used by
Telemarketers!

.:: Security Publications ::.
-- Computer Incident Advisory Capability
-- Call And Response Telephone Compilations
-- Forbidden Knowledge
-- Keen Veracity
-- Lexxicor
-- Midnight Hackers Private Club
-- Phrack
-- Risks Forum Digest
-- Tricks Of The Trade
-- Underground Periodical

.:: Law, Privacy, Wetware, Hardware, File Sharing and more ::.
1. HARDWARE - Hardware, Electronics, Radio etc.
-- TEMPEST
-- Bugs and Listening Devices
-- Miscellaneous

2. Hackers and the Law
-- Copyright Law and Cases
-- Net Censorship
-- Cases involving 2600 Magazine
-- The SDMI affair
-- Brian West
-- September 11th Backlash Legislation
-- General Legal Bufu

3. About Napster, Gnutella, and other File Sharing schemes

4. About your dwindling privacy
-- Privacy Digest
-- Internet Privacy
-- Espionage
-- Privacy Deprivation Tools

5. Wetware Hacking!
-- Social Engineering and NLP
-- Seduction
-- Miscellaneous Wetware Hacking

6. Physical Security, Scams etc...
-- Physical Security and Countersecurity
-- Financial Crimes Detection and Prevention
-- Vending Machine Hacking

.:: The standards that define the Internet ::.
1. RFCs - Internet RFCs 3094 to 3195
-- Internet RFCs 3094 to 3195

2. Other Standards and Official Publications
-- US Department of Energy CIAC-2300 Documents
-- NIPC CyberNotes

--- Thank You ---

Source: http://www.fx-vista.com

 

So my idea was to put the question to all of you what to do in case of
uncompressibility? Any ideas?

How about sending the excess data by post?

What makes this an electronics problem anyway?