Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 153725

Article: 153725
Subject: Re: Smallest GPL UART
From: Frank Buss <fb@frank-buss.de>
Date: Tue, 01 May 2012 22:14:44 +0200
Links: << >>  << T >>  << A >>
Giuseppe Marullo wrote:
> Jan, Frank, Tim, Nico and Andy,
> many thanks for your answer. I would like to stick with Verilog, at the
> moment I am trying with the following code:

Looks good, it uses the same idea I've used, sampling in the middle of a
bit after the start bit detection. This is not perfect, better receivers
use e.g. 8 times oversampling and a majority algorithm, but should work,
if your signal is not too noisy.

But you should latch the rx input, to avoid metastability problems. I
don't know how to do this in Verilog, something like declare another reg
with the name "rx", rename the raw input signal and copy it on rising
clock edge to "rx".

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Article: 153726
Subject: Re: Smallest GPL UART
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Tue, 1 May 2012 21:17:58 +0000 (UTC)
Links: << >>  << T >>  << A >>
Frank Buss <fb@frank-buss.de> wrote:

(snip)
> But you should latch the rx input, to avoid metastability problems. I
> don't know how to do this in Verilog, something like declare another reg
> with the name "rx", rename the raw input signal and copy it on rising
> clock edge to "rx".

Can you explain the problem that you are considering?

Not that slow logic can't have metastability problems, 
but in this case I wouldn't expect it.

-- glen


Article: 153727
Subject: Re: Smallest GPL UART
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 02 May 2012 00:46:56 +0200
Links: << >>  << T >>  << A >>
glen herrmannsfeldt wrote:
> Frank Buss <fb@frank-buss.de> wrote:
> 
> (snip)
>> But you should latch the rx input, to avoid metastability problems. I
>> don't know how to do this in Verilog, something like declare another reg
>> with the name "rx", rename the raw input signal and copy it on rising
>> clock edge to "rx".
> 
> Can you explain the problem that you are considering?

http://www.altera.com/literature/wp/wp-01082-quartus-ii-metastability.pdf

> Not that slow logic can't have metastability problems, 
> but in this case I wouldn't expect it.

My experience differs: I've used my simple UART receiver in a design
with 115,200 baud, and without the buffer, the state machine halted
(going to an invalid state, as I debugged with an "other" case branch,
which was logically impossible) once every some hour. There was lots of
high-speed logic behind the receiver and I've used only the classic
timing analyzer of an old version of Quartus, so maybe in simpler
designs, and with proper timing constraints for the rx signal, there
would be no problem.

But it is good design practice to buffer just any signal, which is fed
asynchronously to the FPGA, then you don't have such problems, even if
you didn't calculate and define all timing constraints.

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Article: 153728
Subject: Re: Smallest GPL UART
From: Tim Wescott <tim@seemywebsite.com>
Date: Tue, 01 May 2012 18:22:18 -0500
Links: << >>  << T >>  << A >>
On Wed, 02 May 2012 00:46:56 +0200, Frank Buss wrote:

> glen herrmannsfeldt wrote:
>> Frank Buss <fb@frank-buss.de> wrote:
>> 
>> (snip)
>>> But you should latch the rx input, to avoid metastability problems. I
>>> don't know how to do this in Verilog, something like declare another
>>> reg with the name "rx", rename the raw input signal and copy it on
>>> rising clock edge to "rx".
>> 
>> Can you explain the problem that you are considering?
> 
> http://www.altera.com/literature/wp/wp-01082-quartus-ii-
metastability.pdf
> 
>> Not that slow logic can't have metastability problems, but in this case
>> I wouldn't expect it.
> 
> My experience differs: I've used my simple UART receiver in a design
> with 115,200 baud, and without the buffer, the state machine halted
> (going to an invalid state, as I debugged with an "other" case branch,
> which was logically impossible) once every some hour. There was lots of
> high-speed logic behind the receiver and I've used only the classic
> timing analyzer of an old version of Quartus, so maybe in simpler
> designs, and with proper timing constraints for the rx signal, there
> would be no problem.
> 
> But it is good design practice to buffer just any signal, which is fed
> asynchronously to the FPGA, then you don't have such problems, even if
> you didn't calculate and define all timing constraints.

It might be a good practice to have that "other" case statement feeding a 
master reset or some other more sensible response to a bad state than 
wedging the FPGA, too.

Just sayin'

-- 
My liberal friends think I'm a conservative kook.
My conservative friends think I'm a liberal kook.
Why am I not happy that they have found common ground?

Tim Wescott, Communications, Control, Circuits & Software
http://www.wescottdesign.com

Article: 153729
Subject: Re: Smallest GPL UART
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Tue, 01 May 2012 19:09:18 -0500
Links: << >>  << T >>  << A >>
In article <jnpp51$2vn$1@newsreader4.netcologne.de>,
 Frank Buss <fb@frank-buss.de> writes:

>My experience differs: I've used my simple UART receiver in a design
>with 115,200 baud, and without the buffer, the state machine halted
>(going to an invalid state, as I debugged with an "other" case branch,
>which was logically impossible) once every some hour. There was lots of
>high-speed logic behind the receiver and I've used only the classic
>timing analyzer of an old version of Quartus, so maybe in simpler
>designs, and with proper timing constraints for the rx signal, there
>would be no problem.

It doesn't take metastability to do that.  You will miss setup/hold
if the signal has different timing paths to different FFs.  One
FF will see the old version of the signal and another FF will see
the new version.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 153730
Subject: Re: Smallest GPL UART
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 2 May 2012 01:11:04 +0000 (UTC)
Links: << >>  << T >>  << A >>
Tim Wescott <tim@seemywebsite.com> wrote:
> On Wed, 02 May 2012 00:46:56 +0200, Frank Buss wrote:
>> glen herrmannsfeldt wrote:
>>> Frank Buss <fb@frank-buss.de> wrote:
 
>>> (snip)
>>>> But you should latch the rx input, to avoid metastability problems. I
>>>> don't know how to do this in Verilog, something like declare another
>>>> reg with the name "rx", rename the raw input signal and copy it on
>>>> rising clock edge to "rx".
 
>>> Can you explain the problem that you are considering?

(snip)
>>> Not that slow logic can't have metastability problems, 
>>> but in this case I wouldn't expect it.
 
>> My experience differs: I've used my simple UART receiver in a design
>> with 115,200 baud, and without the buffer, the state machine halted
>> (going to an invalid state, as I debugged with an "other" case branch,
>> which was logically impossible) once every some hour. 

OK, I suppose I could have looked at the actual logic before writing.

Yes, if one isn't careful with a state machine, it can have
metastability problems even with a slow clock.

There is also that Quartus likes to rearrange state machines logic,
such that it isn't like it is written. Some years ago, I found a
bug in Quartus where it converted to a one-hot state machine even
though I was using the state value in the design. (It had four
states, and as written two state bits. Quartus converted to one-hot
and gave two of the four as state bits.) 

>> There was lots of
>> high-speed logic behind the receiver and I've used only the classic
>> timing analyzer of an old version of Quartus, so maybe in simpler
>> designs, and with proper timing constraints for the rx signal, there
>> would be no problem.
 
>> But it is good design practice to buffer just any signal, which is fed
>> asynchronously to the FPGA, then you don't have such problems, even if
>> you didn't calculate and define all timing constraints.

Yes, if the design is such that more than one FF latches the same
input, and can fail if different values are latched on the same
clock cycle.

> It might be a good practice to have that "other" case statement feeding 
> a master reset or some other more sensible response to a bad state than 
> wedging the FPGA, too.

That seems to be the easy way to fix it. 

Now, it is likely that one additional clock cycle won't affect much, 
but one does have to consider that in terms of the overall logic.

-- glen

Article: 153731
Subject: Re: Smallest GPL UART
From: Frank Buss <fb@frank-buss.de>
Date: Wed, 02 May 2012 07:43:02 +0200
Links: << >>  << T >>  << A >>
Hal Murray wrote:
> In article <jnpp51$2vn$1@newsreader4.netcologne.de>,
>  Frank Buss <fb@frank-buss.de> writes:
> 
>> My experience differs: I've used my simple UART receiver in a design
>> with 115,200 baud, and without the buffer, the state machine halted
>> (going to an invalid state, as I debugged with an "other" case branch,
>> which was logically impossible) once every some hour. There was lots of
>> high-speed logic behind the receiver and I've used only the classic
>> timing analyzer of an old version of Quartus, so maybe in simpler
>> designs, and with proper timing constraints for the rx signal, there
>> would be no problem.
> 
> It doesn't take metastability to do that.  You will miss setup/hold
> if the signal has different timing paths to different FFs.  One
> FF will see the old version of the signal and another FF will see
> the new version.

Right, this is slightly different from metastability, and maybe was the
reason for the behaviour in my FPGA program, though the bugfix is the
same :-)

Is there a technical term for this special kind of problem?

-- 
Frank Buss, http://www.frank-buss.de
electronics and more: http://www.youtube.com/user/frankbuss

Article: 153732
Subject: Re: Smallest GPL UART
From: Arlet Ottens <usenet+5@c-scape.nl>
Date: Wed, 02 May 2012 08:59:03 +0200
Links: << >>  << T >>  << A >>
On 05/02/2012 12:46 AM, Frank Buss wrote:

>>> But you should latch the rx input, to avoid metastability problems. I
>>> don't know how to do this in Verilog, something like declare another reg
>>> with the name "rx", rename the raw input signal and copy it on rising
>>> clock edge to "rx".
>>
>> Can you explain the problem that you are considering?
>
> http://www.altera.com/literature/wp/wp-01082-quartus-ii-metastability.pdf
>
>> Not that slow logic can't have metastability problems,
>> but in this case I wouldn't expect it.
>
> My experience differs: I've used my simple UART receiver in a design
> with 115,200 baud, and without the buffer, the state machine halted
> (going to an invalid state, as I debugged with an "other" case branch,
> which was logically impossible) once every some hour. There was lots of
> high-speed logic behind the receiver and I've used only the classic
> timing analyzer of an old version of Quartus, so maybe in simpler
> designs, and with proper timing constraints for the rx signal, there
> would be no problem.

Usually these problems are the result of an incoming asynchronous 
signal, like a UART RxD, going to two different inputs in the FPGA at 
the same time.

When the signal has an undefined voltage right at the clock edge, one 
input could capture it as a '0', and the other input as a '1', 
potentially resulting in inconsistent states.

Note that this has nothing to do with metastability.

Article: 153733
Subject: Re: Smallest GPL UART
From: Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid>
Date: Wed, 02 May 2012 09:10:39 +0200
Links: << >>  << T >>  << A >>
In comp.arch.fpga,
Frank Buss <fb@frank-buss.de> wrote:
> Hal Murray wrote:
>> 
>> It doesn't take metastability to do that.  You will miss setup/hold
>> if the signal has different timing paths to different FFs.  One
>> FF will see the old version of the signal and another FF will see
>> the new version.
>
> Right, this is slightly different from metastability, and maybe was the
> reason for the behaviour in my FPGA program, though the bugfix is the
> same :-)
>
> Is there a technical term for this special kind of problem?

Race condition


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Experience varies directly with equipment ruined.

Article: 153734
Subject: Re: Smallest GPL UART
From: "langwadt@fonz.dk" <langwadt@fonz.dk>
Date: Wed, 2 May 2012 14:13:15 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Apr 30, 7:17=A0pm, Tim Wescott <t...@seemywebsite.com> wrote:
> On Mon, 30 Apr 2012 00:22:50 +0000, Nico Coesel wrote:
> > Giuseppe Marullo <giuseppe.marullonos...@iname.com> wrote:
>
> >>Hi all,
> >>I am searching for the smallest/simpler UART in verilog. I need to
> >>release the project under GPL and still confused about what are my
> >>options.
>
> >>I would go with micro UART by Jeung Joon Lee but I am unable to
> >>determine its license.
>
> >>There are others, like osvudu by Timothy Goddard seems released under
> >>(a) MIT license, thus compatible with GPL.
>
> >>I need very simple stuff:
>
> >>baud rate 9600-115200 with a clock of about 100MHz but should be able t=
o
> >>run with other clocks, like 12MHz. No buffers and other fancy stuff.
>
> >>8N1, and possibility (I need some) to have rtx, tx and rx only
> >>capability (I would like to instantiate just the parts I need).
>
> >>Don't know if I need fullduplex, possibly yes.
>
> >>What would you advice to use?
>
> > There is a very simple UART packed togethet with Xilinx's KCPSM. I agre=
e
> > with the others. Open Source UARTs are not always the best solution. I
> > once used the 16550 UART from opencores but it is pretty crappy. Very
> > slow due to an overly complex design.
>
> A design that did a good job of emulating the 16550 would have to be a
> lot more complex than just a good asynchronous receiver-transmitter.
> pair. =A0Particularly if you can hard-code the division ratio, bit count,
> etc., they are easy-peasy thing to write.
>
> Certainly "overly complex" if you just need a serial interface -- but
> maybe not so if you must have compatibility with existing software.
>
> (Note: I don't know at what point in the process one loses the
> "universal" moniker -- but hard-coding all the bits that are normally
> software programmable would seem to be it).
>

one "universal" thing I almost always use when I need a uart in an
FPGA
is to generate the baudrate with a DDS

very simple and able to hit almost any baud rate at any clock rate

-Lasse

Article: 153735
Subject: Re: Smallest GPL UART
From: Andy <jonesandy@comcast.net>
Date: Thu, 3 May 2012 05:14:48 -0700 (PDT)
Links: << >>  << T >>  << A >>
On May 1, 8:11=A0pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:
> Tim Wescott <t...@seemywebsite.com> wrote:
> > On Wed, 02 May 2012 00:46:56 +0200, Frank Buss wrote:
> >> glen herrmannsfeldt wrote:
> >>> Frank Buss <f...@frank-buss.de> wrote:
> >>> (snip)
> >>>> But you should latch the rx input, to avoid metastability problems. =
I
> >>>> don't know how to do this in Verilog, something like declare another
> >>>> reg with the name "rx", rename the raw input signal and copy it on
> >>>> rising clock edge to "rx".
> >>> Can you explain the problem that you are considering?
>
> (snip)
>
> >>> Not that slow logic can't have metastability problems,
> >>> but in this case I wouldn't expect it.
> >> My experience differs: I've used my simple UART receiver in a design
> >> with 115,200 baud, and without the buffer, the state machine halted
> >> (going to an invalid state, as I debugged with an "other" case branch,
> >> which was logically impossible) once every some hour.
>
> OK, I suppose I could have looked at the actual logic before writing.
>
> Yes, if one isn't careful with a state machine, it can have
> metastability problems even with a slow clock.
>
> There is also that Quartus likes to rearrange state machines logic,
> such that it isn't like it is written. Some years ago, I found a
> bug in Quartus where it converted to a one-hot state machine even
> though I was using the state value in the design. (It had four
> states, and as written two state bits. Quartus converted to one-hot
> and gave two of the four as state bits.)
>
> >> There was lots of
> >> high-speed logic behind the receiver and I've used only the classic
> >> timing analyzer of an old version of Quartus, so maybe in simpler
> >> designs, and with proper timing constraints for the rx signal, there
> >> would be no problem.
> >> But it is good design practice to buffer just any signal, which is fed
> >> asynchronously to the FPGA, then you don't have such problems, even if
> >> you didn't calculate and define all timing constraints.
>
> Yes, if the design is such that more than one FF latches the same
> input, and can fail if different values are latched on the same
> clock cycle.
>
> > It might be a good practice to have that "other" case statement feeding
> > a master reset or some other more sensible response to a bad state than
> > wedging the FPGA, too.
>
> That seems to be the easy way to fix it.
>
> Now, it is likely that one additional clock cycle won't affect much,
> but one does have to consider that in terms of the overall logic.
>
> -- glen

Including a "when others =3D> state <=3D reset"; will not help unless you
turn off state machine optimization, or invoke other "safe" state
machine synthesis settings. One of the optimizations most any
synthesizer worth its salt will do is remove "unreachable" states
(those states that do not have a coded assignment or path to them.)
Thus since "others" is not directly reachable, it gets optimized out,
along with anything it was doing.

There are multiple ways of dealing with this, most depend either on
invoking synthesis tool settings or turning off state machine
optimizations and manually handling it yourself in the RTL (such as
with a "when others". Be careful though; some of the simplest to code
methods result in the worst utilization and performance.

However, it is best to handle the root of the problem, which is an
improperly synchronized asynchronous input.

The term for this problem is not "race condition" it is an "improper
parallel synchronizer", or a  circuit that clocks the same
asynchronous input into more than one register in parallel.

A "race condition" is when proper operation requires that one
combinatorial path must be faster than another.

Andy

Article: 153736
Subject: Re: Smallest GPL UART
From: Martin Thompson <martin.j.thompson@trw.com>
Date: Thu, 03 May 2012 17:45:57 +0100
Links: << >>  << T >>  << A >>
Tim Wescott <tim@seemywebsite.com> writes:

>> But it is good design practice to buffer just any signal, which is fed
>> asynchronously to the FPGA, then you don't have such problems, even if
>> you didn't calculate and define all timing constraints.

Mandatory, I'd say, unless you can make a cast-iron argument as to why it
doesn't matter if it is sampled differently by two different flops.

>
> It might be a good practice to have that "other" case statement feeding a 
> master reset or some other more sensible response to a bad state than 
> wedging the FPGA, too.

You'd think, wouldn't you?

But ( at least in VHDL) you also have to be aware that synthesis tools
(unless you do some hoop-jumping) are "clever" enough to "know" that you
can't get to those invalid states (especially in VHDL when using an
enumerated type: in language terms, anything outside the enumeration
doesn't exist!).

So they optimise out your nice recovery logic :(

Quartus has an attribute to make the synth put its own reset logic in for
invalid states, to go back to the reset state.

XST has an attribute to specify the safe state it should go to when
state is invalid.  And another to enable that behaviour.

Synplify has an option to generate logic to put things back to the reset
state if an illegal state is detected.

None of which makes the implementation match the code...

Synplify also has an option to create an "exact" state machine, which
does do precisely what your code says (or so it claims) at the expense
of disabling all its clever optimisations for that machine.

Take your pick :)

Cheers,
Martin





>
> Just sayin'

-- 
martin.j.thompson@trw.com 
TRW Conekt - Consultancy in Engineering, Knowledge and Technology
http://www.conekt.co.uk/capabilities/39-electronic-hardware

Article: 153737
Subject: Re: FPGA communication with a PC (Windows)
From: "ralph" <ralph.li@n_o_s_p_a_m.oce.com>
Date: Thu, 03 May 2012 14:38:18 -0500
Links: << >>  << T >>  << A >>
From my experience Ethernet is definitely a good way to do it (1000BASE-T).
I have written a simple MAC layer on SP605 board (with PHY) which only
deals with ARP, ICMP (for ping), and UDP protocols.

I got approx. 50MBytes downloading speed(from PC to FPGA) with UDP
(1024bytes payload). Uploading speed not measured though. But I think it
should meet 20MBps requriement if software can catch and store the data
quicker enough.

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153738
Subject: Re: Wow! No TestbenchWow!
From: "daniel.kho" <daniel.kho@n_o_s_p_a_m.gmail.com>
Date: Thu, 03 May 2012 14:39:27 -0500
Links: << >>  << T >>  << A >>
Sorry I came in late for this one.

>`timescale 1ns/1ns
>
>module simulatedUartTransmitter(output reg TxD);
>  time bitTime;
>  //
>  task setBitTime(input time newBitTime);
>    bitTime = newBitTime;
>  endtask
>
>  task sendChar(input [7:0] char);
>    begin
>      // send start bit
>      TxD = 0;
>      // send eight data bits, LSB first
>      repeat (8) begin
>        #(bitTime) TxD = char[0];
>        char = char >> 1;
>      end
>      // send stop bit
>      #(bitTime) TxD = 1;
>      #(bitTime);
>    end
>  endtask
>  //
>  initial TxD = 1;  // line idles in "Mark" state
>  //
>endmodule
>
>module justTryThisOne;
>  // connections
>  wire serial_TxD;
>  // stimulus generator instance
>  simulatedUartTransmitter txGenerator(.TxD(serial_TxD));
>  //
>  // There's no DUT in this example, but you can still
>  // see the signal generator at work.
>  //
>  // code to generate some stimulus
>  initial begin
>    txGenerator.setBitTime(104000);  // 9600Bd, roughly
>    #1_000_000;  // idle awhile before starting
>    txGenerator.sendChar("h");  // ask the sig-gen...
>    txGenerator.sendChar("i");  // ...to send some data
>    txGenerator.sendChar("!");  // ...at our request
>    #1_000_000; // idle awhile at the end
>  end
>endmodule


I'm still quite new to VHDL external names. But I thought this is already
possible with VHDL-2008?

The simulatedUartTransmitter just looks like a package to me, with a few
procedures:

library ieee; use ieee.std_logic_1164.all;
package uartPkg is
    type simulatedUartTransmitter is protected
        procedure setBitTime(newBitTime:in time);
        procedure sendChar(char:in character);
    end protected simulatedUartTransmitter;
    
    signal TxD:std_ulogic;
    shared variable uartTx: simulatedUartTransmitter;
end package uartPkg;

package body uartPkg is
    type simulatedUartTransmitter is protected body
        variable bitTime:time;
        procedure setBitTime(newBitTime:in time) is begin
            bitTime:=newBitTime;
        end procedure setBitTime;
        
        procedure sendChar(char:in character) is begin
            /* use wait statements to wait on bitTime. */
            ...
        end procedure sendChar;
    end protected body simulatedUartTransmitter;
end package body uartPkg;

/* The testbench. */
library ieee; use ieee.std_logic_1164.all;
entity justTryThisOne is end entity justTryThisOne;

architecture noTestbenchInst of justTryThisOne is
    signal serial_TxD: std_ulogic;
    alias txGenerator is <<variable @work.uartPkg.uartTx:
@work.uartPkg.simulatedUartTransmitter>>;
begin
    tester: process is begin
        txGenerator.setBitTime(104000);
        wait for 1 us;
        txGenerator.sendChar('h');
        txGenerator.sendChar('i');
        txGenerator.sendChar('!');
        wait for 1 us;
    end process tester;
end architecture noTestbenchInst;

I haven't tried this with any simulator, but it might just work.

regards, daniel

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153739
Subject: Re: Wow! No TestbenchWow!
From: "daniel.kho" <daniel.kho@n_o_s_p_a_m.gmail.com>
Date: Thu, 03 May 2012 14:39:41 -0500
Links: << >>  << T >>  << A >>
>One question though: if the task sendChar is called concurrently from
>different procedural blocks in a way that the calls are overlapping, I
>think the result would be a great mess (I am saying this as a not so
great
>lover of how Verilog works).
>
>Is there a simple way to deal with collisions like that? Or will the
>simplicity be lost then for the most part?

That's the reason why we have to use protected types to access
methods/functions directly from a package or another entity. :)
Peter Ashenden's book explains well...

regards, daniel

	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

Article: 153740
Subject: L3 protocol for transmission from small FPGA to embedded Linux system
From: Wojciech M. Zabolotny <wzab@ise.pw.edu.pl>
Date: Thu, 3 May 2012 21:42:01 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hi,

I'd like to share with you my last development - a L3 
protocol for transmission of data between low resources
FPGA and an embedded system.

It may allow you to use low cost/low resources FPGAs
together with cheap Ethernet switches and simple 
Linux based embedded systems (or just reflashed 
Linux based Ethernet routers working as both a switch
and an embedded system) to create data acquisition
systems concentrating data from multiple channels.

Because the Ethernet link  does not provide reliable
transfer of packet, we need to assure an acknowledge
mechanism (like in TCP).
However if the transfer speed is R bytes/second, and
the maximum acknowledge latency is T, then we need
to buffer at least R*T bytes. The problem is that
at transfer rates of 100Mb/s or 1Gb/s the latency
must be really small if we want to use only internal 
RAM of FPGA for buffering.
E.g. for 100Mb/s (roughly 10MB/s) and 40kB of internal RAM,
we can accept latency of only 4ms. For 1GB/s it could
be only 400┬Ás.

To keep latency as low as possible, I've decided to 
implement my transmission as L3 protocol.
As it is supposed to be used only in private networks,
I have decided to use unregistered 0xfade Ethernet type.

The sources of both: FPGA part (designed for Xilinx
SP601 board, but written with portability in mind)
and of Linux driver (compiled with kernel 3.3.3, but
should work also with other 3.x kernels) are published
on the alt.usenet group.
See the post: "L3 protocol for data transmission
from low resource FPGA to Linux embedded system"
The link to the Google archive is:
http://groups.google.com/group/alt.sources/browse_thread/thread/2c2511659f5869c5

I'll publish newer versions of my sources also
on my website (yet almost empty):
http://www.ise.pw.edu.pl/~wzab/fpga_l3_fade

Generally the system is very simple.
The kernel module may receive data from a few 
FPGA based "slave" devices (defined by the "max_slaves"
parameters, when loading the module).
Data received from each slave are written to the kernel
buffer, which should be mmapped to the user application,
which is supposed to preprocess the data and possibly
send the result further through standard TCP/IP 
connections.

The system of course doesn't handle routing (due
to low latency requirements). 
The FPGA even doesn't need to handle ARP protocol.
In the user application we need simply to register
a slave with particular MAC connected to the
particular network interface, and this slave will
be visible as /dev/l3_fpga0, /dev/l3_fpga1 and 
so on.
In my sources there is a very simple application,
which connects to the slave, and verifies, that this
slave sends consecutive integers.

In system like this a nontrivial problem is to set
the appropriate rate of packets sent from the
slave to the embedded system.
In my system it is achieved by introducing of certain
delay between the data packets.
This delay is adaptively adjusted during the operation
of the system. The appropriate delay is found
analysing the ratio between all sent packets and
retransmitted packets: Nretr/Nall
If the data packets are sent too quickly, the acknowledge
packets from the embedded system are received too late,
and the packet is retransmitted before acknowledge arrives.
The same may occur if the embedded system is overloaded 
with packets from different slaves and drops some packets.
Therefore if the Nretr/Nall is too high, we have to 
increase the delay. If the ratio Nretr/Nall is near to 0,
we may reduce the delay.
Such a simple algorithm works quite satisfactory.

The sources are published partly under the GPL licence
(the Linux driver and user application) and partly
under the BSD license (my FPGA sources).
Sources of FPGA part contain also very slightly 
modified Ethernet MAC 
http://opencores.org/project,ethernet_tri_mode
which is published under LGPL.
Unfortunately, I was not able to publish all
parts generated by Xilinx tools, therefore I include
only xco files.

Please note, that my sources are the first iteration.
They use some "quick and dirty" solutions.
I hope to prepare more mature version and describe it
in a normal publication (of course I'll send information
about it, as I've done with my sorter:
http://www.ise.pw.edu.pl/~wzab/fpga_heapsort, which 
was also first published in alt.sources and
comp.arch.fpga )

I hope that my solution will be useful for somebody.
-- 
Regards,
Wojciech M. Zabolotny
wzab@ise.pw.edu.pl


Article: 153741
Subject: Re: Wow! No TestbenchWow!
From: Daniel Kho <daniel.kho@gmail.com>
Date: Thu, 3 May 2012 22:56:22 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Friday, May 4, 2012 3:39:27 AM UTC+8, daniel.kho wrote:

> /* The testbench. */
> library ieee; use ieee.std_logic_1164.all;
> entity justTryThisOne is end entity justTryThisOne;
> 
> architecture noTestbenchInst of justTryThisOne is
>     signal serial_TxD: std_ulogic;
>     alias txGenerator is <<variable @work.uartPkg.uartTx:
> @work.uartPkg.simulatedUartTransmitter>>;
> begin
>     tester: process is begin
>         txGenerator.setBitTime(104000);
>         wait for 1 us;
>         txGenerator.sendChar('h');
>         txGenerator.sendChar('i');
>         txGenerator.sendChar('!');
>         wait for 1 us;
>     end process tester;
> end architecture noTestbenchInst;

Sorry, I guess serial_TxD should have been:
    alias serial_TxD is <<signal @work.uartPkg.TxD: std_ulogic>>;
instead of declared as another signal within the architecture.

This way, you can check/monitor the output of the UART from this same testbench.

-daniel

Article: 153742
Subject: FPGA and Package-on-Package
From: acd <acd4usenet@lycos.de>
Date: Fri, 4 May 2012 06:40:44 -0700 (PDT)
Links: << >>  << T >>  << A >>
Since the Beagleboard and the Raspberry Pi use Package-on-Packge for integr=
ating Flash and DRAM with the processor SoC I wonder why the FPGA vendors d=
o not offer this. There are many FPGA-designs that need external memory and=
 the pins to the base PCB are valuable resource.=20

Not even Silicon Blue (now lattice) who targeted the mobile market offered =
it, as far as I could find.=20
Even though, the offered memories for PoP are limited, every new product th=
at integrates with them would expand that spectrum.=20
With the new FPGA-SoCs (Xilinx ZYNC, Altera "SoC FPGA") the issue might cha=
nge.=20

Andreas

Article: 153743
Subject: Re: FPGA communication with a PC (Windows)
From: "Dr. Beau Webber" <j.b.w.webber@kent.ac.uk>
Date: Fri, 4 May 2012 12:04:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, 27 March 2012 12:10:18 UTC+1, Bill Valores  wrote:
> Hello all,
> 
> My team needs to design our own piece of testing equipment for our
> project. I'll spare you the gory details, and just say that we will
> need to collect data at some 20 Mbyte/sec (possibly continuously) and
> somehow get it to a PC computer running Windows. 

Hi Bill,
See my post of the 28 May, or, to see it with embedded example YouTube videos, go see :
FPGA Modular Firmware Skeleton for multiple instruments - Morph-IC-II, YouTube videos.
 http://www.element14.com/community/groups/fpga-group/blog/2012/04/28/fpga-modular-firmware-skeleton-for-multiple-instruments--morph-ic-ii-youtube-videos

This does just what you want - 60MB.s-1 burst, (how much you get continuous depends on the PC and what else you are doing on the USB bus).

It provides the USB interface to a group of instrument interfaces - what you build into each interface is up to you.
Not free - very low price for individual use, a good value price for commercial use, would cost you much more to develop.
You just need to talk to a .dll to drive it - example code for testing provided -  See videos for example use.
cheers,  Dr. Beau Webber

Article: 153744
Subject: Re: Smallest GPL UART
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Fri, 04 May 2012 17:15:11 -0500
Links: << >>  << T >>  << A >>
In article <pv5y5p9w6uy.fsf@trw.com>,
 Martin Thompson <martin.j.thompson@trw.com> writes:
>Tim Wescott <tim@seemywebsite.com> writes:
>
>>> But it is good design practice to buffer just any signal, which is fed
>>> asynchronously to the FPGA, then you don't have such problems, even if
>>> you didn't calculate and define all timing constraints.
>
>Mandatory, I'd say, unless you can make a cast-iron argument as to why it
>doesn't matter if it is sampled differently by two different flops.

Even if you are sure it doesn't matter, you aren't out of the water yet.

You still have to consider metastability.

You also have to consider the design lifetime.  Will the guy who
changes something in this area several years from now be smart
enough to know that he needs check again?  Will he get it right?

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 153745
Subject: Re: Smallest GPL UART
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Fri, 4 May 2012 22:33:51 +0000 (UTC)
Links: << >>  << T >>  << A >>
Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:

(snip)
>> Mandatory, I'd say, unless you can make a cast-iron argument as 
>> to why it doesn't matter if it is sampled differently by 
>> two different flops.

> Even if you are sure it doesn't matter, you aren't out of the water yet.

> You still have to consider metastability.

In most cases, for slow logic you don't. 

Metastability becomes a problem if the logic after the FF is
long enough, and the FF is likely (ever) to be metastable long
enough to cause problems. 

Note that you can never get rid of metastability, but only
make it unlikely enough to cause a problem. In high speed
designs, the logic delay is a significant part of a clock cycle,
and even a short metastability can be long enough.

> You also have to consider the design lifetime.  Will the guy who
> changes something in this area several years from now be smart
> enough to know that he needs check again?  Will he get it right?

As with metastability, there is no way to avoid that.

-- glen

Article: 153746
Subject: Re: FPGA and Package-on-Package
From: j.m.granville@gmail.com
Date: Fri, 4 May 2012 19:48:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Saturday, May 5, 2012 1:40:44 AM UTC+12, acd wrote:
> Since the Beagleboard and the Raspberry Pi use Package-on-Packge for inte=
grating Flash and DRAM with the processor SoC I wonder why the FPGA vendors=
 do not offer this. There are many FPGA-designs that need external memory a=
nd the pins to the base PCB are valuable resource.=20
>=20
> Not even Silicon Blue (now lattice) who targeted the mobile market offere=
d it, as far as I could find.=20
> Even though, the offered memories for PoP are limited, every new product =
that integrates with them would expand that spectrum.=20
> With the new FPGA-SoCs (Xilinx ZYNC, Altera "SoC FPGA") the issue might c=
hange.=20
>=20
> Andreas

 Xilinx has dropped some hints on this, but I think the bigger issue, is th=
e FPGA is FAR LESS price sensitive, and MORE performance sensitive, than th=
e products that use Stacked-Die.

 So, the top end FPGA's simply add more on chip RAM, and sell you a bigger =
part!!

 You are quite right tho, that there is an opening for a smaller FPGA, or l=
arger CPLD, tightly coupled to RAM.

 Even here, the issue is volume, as the really big players like Broadcom, c=
an get good enough performance from their Stacked approach, to tackle 98% o=
f the high volume markets - that leaves the crumbs for the PLD vendor.


Article: 153747
Subject: Re: Smallest GPL UART
From: hal-usenet@ip-64-139-1-69.sjc.megapath.net (Hal Murray)
Date: Fri, 04 May 2012 22:37:55 -0500
Links: << >>  << T >>  << A >>
In article <jo1lgf$e5r$1@speranza.aioe.org>,
 glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
>Hal Murray <hal-usenet@ip-64-139-1-69.sjc.megapath.net> wrote:
...

>> Even if you are sure it doesn't matter, you aren't out of the water yet.
>> You still have to consider metastability.

>In most cases, for slow logic you don't. 

Good point.  Thanks.


The key idea being "slow logic" where the metastability settling time
is small relative to the cycle time.

-- 
These are my opinions, not necessarily my employer's.  I hate spam.


Article: 153748
Subject: Re: Smallest GPL UART
From: j.m.granville@gmail.com
Date: Sat, 5 May 2012 17:54:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Wednesday, May 2, 2012 5:43:02 PM UTC+12, Frank Buss wrote:
> Right, this is slightly different from metastability, and maybe was the
> reason for the behaviour in my FPGA program, though the bugfix is the
> same :-)
> 
> Is there a technical term for this special kind of problem?

 My preference is to call it an Aperture Effect, as it is actually a small, but finite time window, and you can even calculate the width (in ns/ps) of this Aperture, given a large enough data-set sample size.

Article: 153749
Subject: Comparing virtex2 to spartan6
From: Thomas Heller <theller@ctypes.org>
Date: Wed, 09 May 2012 17:32:55 +0200
Links: << >>  << T >>  << A >>
I know this is a question which is difficult to be answered,
but does anyone have an estimate which Spartan-6 fpga has
comparable 'size' as a xc2v1000 or a xc2v3000 fpga?
With 'size' I don't mean chip dimensions, I mean logic
functionality.

A very rough estimate would be enough...

Thanks,
Thomas



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search