Goto page Previous 1, 2, 3
rickman
Guest
Wed Dec 15, 2010 11:46 pm
On Dec 15, 1:40 pm, Andy <jonesa...@comcast.net> wrote:
Quote:
To be able to "know" what hardware you are going to get requires
having a language and description that, from the same code, will
always produce the exact same logic, regardless of required
performance, space, and target architecture. Unfortunately it also
means having a language and description which will not produce
reasonably optimal hardware over all combinations of those same
constraints, given the same code. You can't have it both ways.
I don't think you conclusions come from the facts. An HDL can
unambiguously describe a counter with a carry out and allow that
counter and carry to implemented in any manner the device can
support. If I am using a device that can't implement a counter, why
would I attempt to describe a counter? How could any HDL code that
counts possibly be portable in a system that can't implement a
counter?
Quote:
I think we may have a disconnect with regards to the meaning of
"higher level constructs". If you mean things like hierarchy, etc. I
agree that it should not get in the way of a deterministic hardware
description (and I don't think it does, though your methods of using
the language may not be optimal for this).
Not only should hierarchical design not get in the way of
deterministic design, it is mandatory, otherwise you *would* need to
design every logic element.
Quote:
However, I take "higher level constructs" as being those that support
a behavioral description ("what does the circuit do?", not "what is
the circuit?"), with necessarily less direct mapping to implemented
hardware. It is the use of these constructs that provides the
tremendous increase in productivity over past methods (more primitive
languages and schematics). You would not consider creating a word
processor or spreadsheet in assembler, so why would you create a
complex FPGA design with what amounts to a netlist?
I think you are drawing too fine a line between behavioral and
structural. I am not saying I want to design gates. I am saying I
want to clearly know how my code will be implemented. No, I don't
know exactly how this would be done, but like I've said before, when I
figure it out, I'll start a company and get rich from it.
The first step to developing something new is to realize that there is
an opportunity. Some folks are trying to convince me that my editor
is not adequate and I should consider another tool that "understands"
the language. Before I will evaluate that, I have to recognize that
I'm not happy with my editor. I think a lot of people are very
complacent about their tools. I see things a bit differently.
Rick
Andy
Guest
Thu Dec 16, 2010 3:03 am
On Dec 15, 3:46 pm, rickman <gnu...@gmail.com> wrote:
Quote:
On Dec 15, 1:40 pm, Andy <jonesa...@comcast.net> wrote:
To be able to "know" what hardware you are going to get requires
having a language and description that, from the same code, will
always produce the exact same logic, regardless of required
performance, space, and target architecture. Unfortunately it also
means having a language and description which will not produce
reasonably optimal hardware over all combinations of those same
constraints, given the same code. You can't have it both ways.
I don't think you conclusions come from the facts. An HDL can
unambiguously describe a counter with a carry out and allow that
counter and carry to implemented in any manner the device can
support. If I am using a device that can't implement a counter, why
would I attempt to describe a counter? How could any HDL code that
counts possibly be portable in a system that can't implement a
counter?
I don't think you understand that knowing whether a carry output is
used or not is almost worthless if you don't know which way that carry
output should be created, which then gets us back to performance,
resources, and target architectures. You have a pre-conceived notion
that using a carry output will, in all cases of performance,
resources, and target architecture, be an optimal solution. This is
simply not true.
Using my method (count - 1 < 0), I have seen the same synthesis tool,
for the same target architecture, use the the built-in carry-chain
output (shared), use combination of sub-carry outputs and LUTS, and
just LUTS, depending on what it thought would be optimal (and when I
checked them, I found it had made very good choices!) I would prefer
the synthesis tools figure out for themselves that if I am testing the
output of a down counter with count=0 (which is more readable/
understandable than count-1<0), it could use a carry out if it was
optimal. I would really prefer that it figure out that, if count is
not used anywhere else, it could translate a behavior of counting from
1 to n (which is even more readable/understandable) into a down
counter from n-1 to zero (if doing so would be more optimal). But
these are synthesis tool issues, not language issues.
Andy
Christopher Head
Guest
Thu Dec 16, 2010 6:30 am
On Wed, 15 Dec 2010 19:02:09 +0100
Alessandro Basili <alessandro.basili_at_cern.ch> wrote:
Quote:
On 12/14/2010 5:40 AM, Christopher Head wrote:
On Mon, 13 Dec 2010 00:23:30 +0100
Alessandro Basili<alessandro.basili_at_cern.ch> wrote:
http://mysite.ncnetwork.net/reszotzl/uart.vhd
Al
Am I missing something, or is the transmitter slightly flawed in
this code? I seem to see the following:
[snip]
4. From this moment, if the application queries the status register,
you will see that TxState_v is IDLE and hence report transmitter
ready.
I believe only 1 clock after TxState_v is IDLE, hence you have a 1
bit stop.
The application could thus immediately strobe another byte of data
into the transmit data register. Then tx_state will transition to
TxState_v = START and, on the next clock, set serial_out_v to '0'.
The application needs to read the 0x04 as status register and if you
check the zoom file you find that read_data_v is 0x04 only one clock
after the TxState_v is idle. Hence the 1 bit stop is guaranteed.
Al
Each bit is actually three clocks wide. As I pointed out in my other
message, you can't actually stomp on the stop bit at these particular
choices of timing, but the UART code nowhere suggests that it's only
usable with values of (clocks/baud) <= 3. Why else would tic_per_bit_g
be a generic parameter instead of a constant?
Chris
Andy
Guest
Thu Dec 16, 2010 4:00 pm
I haven't seen the code, but this would be an excellent place to use a
range constraint on the generic tic_per_bit_g. Failing that, a
concurrent assertion that verifies useable values of the generic(s)
would work. It could actually work better than a range constraint if
there are interdependencies between the values of multiple generics.
Andy
Mike Treseler
Guest
Thu Dec 16, 2010 9:12 pm
On 12/15/2010 9:30 PM, Christopher Head wrote:
Quote:
Each bit is actually three clocks wide. As I pointed out in my other
message, you can't actually stomp on the stop bit at these particular
choices of timing, but the UART code nowhere suggests that it's only
usable with values of (clocks/baud)<= 3. Why else would tic_per_bit_g
be a generic parameter instead of a constant?
This example works fine for baud rates slower than two ticks per bit.
I left it a constant so I could play with it without having to explain
it. Chris, you have the source and a testbench, so feel free to make
any changes you like. My goal was only to demonstrate that variables
may be used for synthesis of luts and flops.
-- Mike Treseler
Christopher Head
Guest
Thu Dec 16, 2010 10:03 pm
On Thu, 16 Dec 2010 12:12:40 -0800
Mike Treseler <mtreseler_at_gmail.com> wrote:
Quote:
On 12/15/2010 9:30 PM, Christopher Head wrote:
Each bit is actually three clocks wide. As I pointed out in my other
message, you can't actually stomp on the stop bit at these
particular choices of timing, but the UART code nowhere suggests
that it's only usable with values of (clocks/baud)<= 3. Why else
would tic_per_bit_g be a generic parameter instead of a constant?
This example works fine for baud rates slower than two ticks per bit.
I left it a constant so I could play with it without having to
explain it. Chris, you have the source and a testbench, so feel free
to make any changes you like. My goal was only to demonstrate that
variables may be used for synthesis of luts and flops.
-- Mike Treseler
Oh, sure, it didn't cause any trouble. I read the code out of
curiosity, liked the style, and then noticed what I thought looked like
a possible problem and wondered if anyone had seen it. So, no big
deal :)
Chris
Paul Colin Gloster
Guest
Fri Dec 24, 2010 7:35 pm
Jan Decaluwe <jan_at_JanDecaluwe.com> sent on December 14th, 2010:
|---------------------------------------------------------------------|
|"[..] |
| |
|I think Verilog will suit you better as a language, you really should|
|consider switching one of these days. However, there is no reason why|
|it would help you with the issues that you say you are seeing here." |
|---------------------------------------------------------------------|
He did try Verilog many months ago, but he has resumed with VHDL.
Paul Colin Gloster
Guest
Fri Dec 24, 2010 7:46 pm
Andy <jonesandy_at_Comcast.net> sent on December 15th, 2010:
|----------------------------------------------------------------------|
|"[..] |
| |
|[..] |
|[..] You have a pre-conceived notion |
|that using a carry output will, in all cases of performance, |
|resources, and target architecture, be an optimal solution. This is |
|simply not true. |
| |
|Using my method (count - 1 < 0), I have seen the same synthesis tool, |
|for the same target architecture, use the the built-in carry-chain |
|output (shared), use combination of sub-carry outputs and LUTS, and |
|just LUTS, depending on what it thought would be optimal (and when I |
|checked them, I found it had made very good choices!) [..] |
|[..] |
|[..] But |
|these are synthesis tool issues, not language issues. |
| |
|Andy" |
|----------------------------------------------------------------------|
Yes, these are good examples of why Rick is naive to expect to know in
advance the efficient output of a synthesizer. If one variable is
always the sum of two other particular variables and these "variables"
are always constant, then the corresponding hardware (if any) should
naturally be less than for three changing variables.
Rick was proposing something which in reality would be uniform and
hence not generally efficient.
Paul Colin Gloster
Guest
Fri Dec 24, 2010 8:00 pm
Tricky <trickyhead_at_Gmail.com> sent on December 15th, 2010:
|---------------------------------------------------------------------|
|"[..] |
|[..] The only way to know what will come out in advance |
|is either with experience or instantiation. [..] |
|[..] |
| |
|[..]" |
|---------------------------------------------------------------------|
It is not possible to know.
Paul Colin Gloster
Guest
Fri Dec 24, 2010 8:44 pm
Rick Collins had sent on December 10th, 2010:
|----------------------------------------------------------------------|
|"[..] |
| |
|What I mean is, if I want a down counter that uses the carry out to |
|give me an "end of count" flag, why can't I get that in a simple and |
|clear manner? It seems like every time I want to design a circuit I |
|have to experiment with the exact style to get the logic I want and it|
|often is a real PITA to make that happen. |
| |
|[..] |
| |
|I guess what I am trying to say is I would like to be able to specify |
|detailed logic rather than generically coding the function and letting|
|a tool try to figure out how to implement it. [..] |
|[..]" |
|----------------------------------------------------------------------|
On December 13th, 2010, Rick has claimed:
|-----------------------------------------------------------------|
|"[..] |
| |
|[..] |
|[..] I am not saying I want to use something similar to assembly|
|language [..] |
|[..] |
| |
|[..]" |
|-----------------------------------------------------------------|
Rick Collins <gnuarm_at_Gmail.com> sent on December 14th, 2010:
|---------------------------------------------------------------------|
|"[..] |
| |
|[..] |
|[..] Like I said somewhere else, if you want a |
|particular solution, the vendors tell you to instantiate. |
|Instantiation is very undesirable since it is not portable across |
|vendors and often not portable across product lines within a vendor!"|
|---------------------------------------------------------------------|
As with many assembly languages for different models in a single
processor family.
|--------------------------------------------------------------------|
|"The language is flexible, that's for sure. [..] |
|[..]" |
|--------------------------------------------------------------------|
As flexible as Lisp or Confluence or Lava?
Goto page Previous 1, 2, 3
