One issue about free hardware

Roger Larsson <roger.larsson@skelleftea.mail.telia.com> wrote in message news:<HN7pc.59087$mU6.238562@newsb.telia.net>...
> Tom Hawkins wrote:
> 
> > 2. With Confluence under GPL, I have yet to receive a single bug
> > report or source code contribution.
> > 
> 
> For some tools it can take a very long time to build a userbase.
> Step 1. You need to know about it.
>         - I know about Confluence.
> Step 2. You need to have something suitable to try it with.
>         - Maybe this summer...
> Step 3. It needs to be good enough.
>         No idea... since I have not tried it yet.
> Step 4a. It needs to have bugs to give you bug reports :-)
> Step 4b. It needs to be incomplete to give you feature requests.

Step 4c. It needs to be programmed in a language that your small
target audience have heard of! How many Verilog/VHDL coders also know
OCaml? C or Java and you might have a chance...

Cheers,
JonB

jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0405140056.23ca67ac@posting.google.com>...
> > > Ok, maybe not that particular case, but most other configurations of
> > > dual-port RAM can be infered. In Verilog at least, isn't this a
> > > problem with the language rather than the FPGA tools (i.e. you can't
> > > write to the same variable from two different processes)?
> > 
> > Verilog does not have this restriction.  I've searched the LRM and
> > I've run testcases through two reputable implementations without
> > complaints (ncverilog, icarus).
> 
> You are correct. Although it is only ever supported for simulation. I
> can kind of understand why though. Take the following:
> 
> module test(c1, c2, a, b, d);
> input c1, c2, a, b;
> output d;
> reg d;
> always @(posedge c1)
> 	d <= a;
> always @(posedge c2)
> 	d <= b;
> endmodule
> 
> What logic would you synthesize it to? Have you tried this with a
> behavioural synthesis tool? Maybe that could do a better job.
>  
> > Hence my frustration.  We can precisely describe a dual port block-ram
> > in Verilog, yet the tools draw a blank.  We can even preset RAMs with
> > values, but most, if not all, completely disregard initial statements.
> 
> Isn't this fixed in v200x? I do agree it's all a bit crap.
>  
> Cheers,
> JonB

BRams are a very special case since most of the time the 2 address are
different so the 2 clock domains are fully independant. If the address
should be the same then the result of the 2 concurrent writes is
undefined but the user should have taken care about that. given that,
the synthesis should be able to handle it with a warning for same
addresses.

regards

johnjakson_usa_com

johnjakson@yahoo.com (john jakson) wrote in message news:<adb3971c.0405141717.7eea7369@posting.google.com>...
> jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0405140056.23ca67ac@posting.google.com>...
> > > > Ok, maybe not that particular case, but most other configurations of
> > > > dual-port RAM can be infered. In Verilog at least, isn't this a
> > > > problem with the language rather than the FPGA tools (i.e. you can't
> > > > write to the same variable from two different processes)?
> > > 
> > > Verilog does not have this restriction.  I've searched the LRM and
> > > I've run testcases through two reputable implementations without
> > > complaints (ncverilog, icarus).
> > 
> > You are correct. Although it is only ever supported for simulation. I
> > can kind of understand why though. Take the following:
> > 
> > module test(c1, c2, a, b, d);
> > input c1, c2, a, b;
> > output d;
> > reg d;
> > always @(posedge c1)
> > 	d <= a;
> > always @(posedge c2)
> > 	d <= b;
> > endmodule
> > 
> > What logic would you synthesize it to? Have you tried this with a
> > behavioural synthesis tool? Maybe that could do a better job.
> >  
> > > Hence my frustration.  We can precisely describe a dual port block-ram
> > > in Verilog, yet the tools draw a blank.  We can even preset RAMs with
> > > values, but most, if not all, completely disregard initial statements.
> > 
> > Isn't this fixed in v200x? I do agree it's all a bit crap.
> >  
> > Cheers,
> > JonB
> 
> BRams are a very special case since most of the time the 2 address are
> different so the 2 clock domains are fully independant. If the address
> should be the same then the result of the 2 concurrent writes is
> undefined but the user should have taken care about that. given that,
> the synthesis should be able to handle it with a warning for same
> addresses.

Sure, but it seemed like the OP was suggesting that synthesis tools
should support everything possible in the language.

Cheers,
JonB

"Jon Beniston" <jon@beniston.com> wrote in message
news:e87b9ce8.0405141709.5ef4798f@posting.google.com...
> Roger Larsson <roger.larsson@skelleftea.mail.telia.com> wrote in message
news:<HN7pc.59087$mU6.238562@newsb.telia.net>...
> > Tom Hawkins wrote:
> >
> > > 2. With Confluence under GPL, I have yet to receive a single bug
> > > report or source code contribution.
> > >
> >
> > For some tools it can take a very long time to build a userbase.
> > Step 1. You need to know about it.
> >         - I know about Confluence.
> > Step 2. You need to have something suitable to try it with.
> >         - Maybe this summer...
> > Step 3. It needs to be good enough.
> >         No idea... since I have not tried it yet.
> > Step 4a. It needs to have bugs to give you bug reports :-)
> > Step 4b. It needs to be incomplete to give you feature requests.
>
> Step 4c. It needs to be programmed in a language that your small
> target audience have heard of! How many Verilog/VHDL coders also know
> OCaml? C or Java and you might have a chance...
>

That's certainly a point when you are looking for code contributions, and
for many open source projects it makes sense to consider that when choosing
the language.  But for something like Confluence, I don't think that Tom is
looking for so much in the way of direct coding help at the moment -
feedback and ideas are important, along with contributions to the library,
examples and documentation (how many good Verilog/VHDL coders are also good
at "normal" software development, especially something as specialised as
implementing functional programming languages, regardless of the language?).
I am a great supporter of choosing the right language (or right tool of any
kind, for that matter) for the job - popularity might be one consideration,
but it's not the only one.  In fact, why would anyone be interested in
confluence in the first place if they were not happy to consider new
languages?  The choice of ocaml makes a lot of sense here, actually - it is
a functional programming language itself (with bits of imperitive language
added - sort of the opposite of Python, but for the same reasons), so it
matches the style of confluence programming well.  It was actually top of my
"languages to learn when I have the time" list, but confluence sneaked in on
top...

Jon Beniston wrote:

>>>Ok, maybe not that particular case, but most other configurations of
>>>dual-port RAM can be infered. In Verilog at least, isn't this a
>>>problem with the language rather than the FPGA tools (i.e. you can't
>>>write to the same variable from two different processes)?
>>
>>Verilog does not have this restriction.  I've searched the LRM and
>>I've run testcases through two reputable implementations without
>>complaints (ncverilog, icarus).
> 
> 
> You are correct. Although it is only ever supported for simulation. I
> can kind of understand why though. Take the following:
> 
> module test(c1, c2, a, b, d);
> input c1, c2, a, b;
> output d;
> reg d;
> always @(posedge c1)
> 	d <= a;
> always @(posedge c2)
> 	d <= b;
> endmodule
> 
> What logic would you synthesize it to? Have you tried this with a
> behavioural synthesis tool? Maybe that could do a better job.
>  

Another interesting question about the proposed
code above is, during a given simulation cycle
if both clocks rise at the same time, which
executes first in simulation?

Can you re-write the code so that one always
has wins or if both happen a the same time
an 'X' is generated on d?


Cheers,
Jim

Jim Lewis wrote:
> 
> Jon Beniston wrote:
> 
> >>>Ok, maybe not that particular case, but most other configurations of
> >>>dual-port RAM can be infered. In Verilog at least, isn't this a
> >>>problem with the language rather than the FPGA tools (i.e. you can't
> >>>write to the same variable from two different processes)?
> >>
> >>Verilog does not have this restriction.  I've searched the LRM and
> >>I've run testcases through two reputable implementations without
> >>complaints (ncverilog, icarus).
> >
> >
> > You are correct. Although it is only ever supported for simulation. I
> > can kind of understand why though. Take the following:
> >
> > module test(c1, c2, a, b, d);
> > input c1, c2, a, b;
> > output d;
> > reg d;
> > always @(posedge c1)
> >       d <= a;
> > always @(posedge c2)
> >       d <= b;
> > endmodule
> >
> > What logic would you synthesize it to? Have you tried this with a
> > behavioural synthesis tool? Maybe that could do a better job.
> >
> 
> Another interesting question about the proposed
> code above is, during a given simulation cycle
> if both clocks rise at the same time, which
> executes first in simulation?
> 
> Can you re-write the code so that one always
> has wins or if both happen a the same time
> an 'X' is generated on d?

Same as in the real world, the result is indeterminate.  

-- 

Rick "rickman" Collins

rick.collins@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.

Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design      URL http://www.arius.com
4 King Ave                               301-682-7772 Voice
Frederick, MD 21701-3110                 301-682-7666 FAX