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 160200

Article: 160200
Subject: Re: minimal HDMI pins to send video ?
From: gtwrek@sonic.net (Mark Curry)
Date: Fri, 4 Aug 2017 20:49:55 -0000 (UTC)
Links: << >>  << T >>  << A >>
In article <501839240@f10.n1.z10.fidonet.org>,
abirov <abirov@f10.n1.z10.fidonet.org> wrote:
>From Newsgroup: comp.arch.fpga
>
>I am VHDL user , how to declare correctly : 
>
>i thought pixclk must be declare like this  :
>
>reg pixclk;
>
>clock instance_name (
>    .CLKIN_IN(clk100), 
>    .CLKDV_OUT(pixclk), 
>    .CLKFX_OUT(DCM_TMDS_CLKFX), 
>    .CLKIN_IBUFG_OUT(clk_TMDS), 
>    .CLK0_OUT(CLK0_OUT)
>    );
>
>ERROR:HDLCompilers:246 - "asdf.v" line 48 Reference to scalar reg 'pixclk' is
>not a legal net lvalue
>ERROR:HDLCompilers:102 - "asdf.v" line 48 Connection to output port 'CLKDV_OUT'
> must be a net lvalue
>SEEN-BY: 1/5 10 101 102 122 126 134 186 2/122 195/0 1

CLKDV_OUT is ( I'm inferring ) an output port.  In verilog-1995 (or -2001), output ports must
drive a net type variable (i.e. wire).
Change the pixclk defintion to:

wire pixclk;

Regards,

Mark



Article: 160201
Subject: additional fpga forums
From: Edward.Moore@f10.n1.z30.fidonet.org (Edward Moore)
Date: Sat, 05 Aug 2017 11:40:19 +1200
Links: << >>  << T >>  << A >>
>From Newsgroup: comp.arch.fpga

suggestions for alternative fpga-related forums ?
SEEN-BY: 1/5 10 101 102 122 126 134 186 2/122 195/0 1


Article: 160202
Subject: Re: additional fpga forums
From: Rick.C..Hodgin@f10.n1.z31.fidonet.org (Rick C. Hodgin)
Date: Sat, 05 Aug 2017 11:42:24 +1200
Links: << >>  << T >>  << A >>
>From Newsgroup: comp.arch.fpga

On Saturday, August 5, 2017 at 2:40:25 PM UTC-4, Edward Moore wrote:
> suggestions for alternative fpga-related forums ?

Try these:

    http://www.eevblog.com/forum/
    https://www.edaplayground.com

Thank you,
Rick C. Hodgin
SEEN-BY: 1/5 10 101 102 122 126 134 186 2/122 195/0 1


Article: 160203
Subject: Re: minimal HDMI pins to send video ?
From: abirov@gmail.com
Date: Fri, 4 Aug 2017 22:05:55 -0700 (PDT)
Links: << >>  << T >>  << A >>
Thank you it works !

Article: 160204
Subject: additional fpga forums
From: Edward Moore <edmoore1966@googlemail.com>
Date: Sat, 5 Aug 2017 11:40:19 -0700 (PDT)
Links: << >>  << T >>  << A >>
suggestions for alternative fpga-related forums ?

Article: 160205
Subject: Re: additional fpga forums
From: "Rick C. Hodgin" <rick.c.hodgin@gmail.com>
Date: Sat, 5 Aug 2017 11:42:24 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Saturday, August 5, 2017 at 2:40:25 PM UTC-4, Edward Moore wrote:
> suggestions for alternative fpga-related forums ?

Try these:

    http://www.eevblog.com/forum/
    https://www.edaplayground.com

Thank you,
Rick C. Hodgin

Article: 160206
Subject: Re: sram
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 6 Aug 2017 05:01:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Tuesday, August 1, 2017 at 7:21:32 PM UTC-4, brim...@gmail.com wrote:

> Generating a synchronously gated WE in a single cycle with a 1x clock can be done fairly easily by using the FPGA's dual-edge output flip-flop primitives.
> 
> I posted some notes on this technique (for a Spartan-3) to the fpga-cpu group many years ago:
>   https://groups.yahoo.com/neo/groups/fpga-cpu/conversations/messages/2076
>   https://groups.yahoo.com/neo/groups/fpga-cpu/conversations/messages/2177
> 

It's even easier than that to synchronously control a standard async SRAM.  Simply connect WE to the clock and hold OE active all the time except for cycles where you want to write something new into the SRAM.

Kevin Jennings

Article: 160207
Subject: Re: sram
From: rickman <gnuarm@gmail.com>
Date: Sun, 6 Aug 2017 12:40:22 -0400
Links: << >>  << T >>  << A >>
KJ wrote on 8/6/2017 8:01 AM:
> On Tuesday, August 1, 2017 at 7:21:32 PM UTC-4, brim...@gmail.com wrote:
>
>> Generating a synchronously gated WE in a single cycle with a 1x clock can be done fairly easily by using the FPGA's dual-edge output flip-flop primitives.
>>
>> I posted some notes on this technique (for a Spartan-3) to the fpga-cpu group many years ago:
>>   https://groups.yahoo.com/neo/groups/fpga-cpu/conversations/messages/2076
>>   https://groups.yahoo.com/neo/groups/fpga-cpu/conversations/messages/2177
>>
>
> It's even easier than that to synchronously control a standard async SRAM.  Simply connect WE to the clock and hold OE active all the time except for cycles where you want to write something new into the SRAM.

That would depend a *lot* on the details of the setup and hold times for the 
async SRAM, no?  You can do what you want with data for much of the clock 
cycle, but the address has to meet setup and hold for the entire WE time. 
That's typically more than half a clock cycle and makes it hard to use it on 
every clock cycle.

-- 

Rick C

Article: 160208
Subject: Re: sram
From: lasselangwadtchristensen@gmail.com
Date: Sun, 6 Aug 2017 10:30:41 -0700 (PDT)
Links: << >>  << T >>  << A >>
Den s=C3=B8ndag den 6. august 2017 kl. 18.40.25 UTC+2 skrev rickman:
> KJ wrote on 8/6/2017 8:01 AM:
> > On Tuesday, August 1, 2017 at 7:21:32 PM UTC-4, brim...@gmail.com wrote=
:
> >
> >> Generating a synchronously gated WE in a single cycle with a 1x clock =
can be done fairly easily by using the FPGA's dual-edge output flip-flop pr=
imitives.
> >>
> >> I posted some notes on this technique (for a Spartan-3) to the fpga-cp=
u group many years ago:
> >>   https://groups.yahoo.com/neo/groups/fpga-cpu/conversations/messages/=
2076
> >>   https://groups.yahoo.com/neo/groups/fpga-cpu/conversations/messages/=
2177
> >>
> >
> > It's even easier than that to synchronously control a standard async SR=
AM.  Simply connect WE to the clock and hold OE active all the time except =
for cycles where you want to write something new into the SRAM.
>=20
> That would depend a *lot* on the details of the setup and hold times for =
the=20
> async SRAM, no?  You can do what you want with data for much of the clock=
=20
> cycle, but the address has to meet setup and hold for the entire WE time.=
=20
> That's typically more than half a clock cycle and makes it hard to use it=
 on=20
> every clock cycle.
>=20

and just using the clock give you the headache of trying to control routing=
=20
delays on data vs. WE=20

using the dual edge output flipflop makes it all much controllable



Article: 160209
Subject: Re: sram
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 6 Aug 2017 10:33:39 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, August 6, 2017 at 12:40:25 PM UTC-4, rickman wrote:
> KJ wrote on 8/6/2017 8:01 AM:
> > It's even easier than that to synchronously control a standard async SRAM.  Simply connect WE to the clock and hold OE active all the time except for cycles where you want to write something new into the SRAM.
> 
> That would depend a *lot* on the details of the setup and hold times for the 
> async SRAM, no?  You can do what you want with data for much of the clock 
> cycle, but the address has to meet setup and hold for the entire WE time. 
> That's typically more than half a clock cycle and makes it hard to use it on 
> every clock cycle.
> 
Address (and data) setup and hold times are easily met.  As a first order approximation, the setup time will be T/2-Tco(max).  The address hold time will be Tco(min).

What is your source for statement "That's typically more than half a clock cycle"?  The ancient Cypress CY62256N lists both of these requirements (Tsa and Tha) as 0 ns [1].

The technique works.  You get single cycle read or write on 100% of the clock cycles, timing is met, period...and it worked 20+ years ago on product I designed [2].

Kevin Jennings

[1] http://www.cypress.com/file/43841/download page 7.
[2] USPTO 6,169,703 (Patent status = Expired) https://patentimages.storage.googleapis.com/8a/c2/3d/f566f483f9e961/US6169703.pdf

Article: 160210
Subject: Re: sram
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 6 Aug 2017 10:40:34 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, August 6, 2017 at 1:30:46 PM UTC-4, lasselangwad...@gmail.com wr=
ote:
> Den s=C3=B8ndag den 6. august 2017 kl. 18.40.25 UTC+2 skrev rickman:
>=20
> and just using the clock give you the headache of trying to control routi=
ng=20
> delays on data vs. WE=20
>=20
> using the dual edge output flipflop makes it all much controllable

Not true.  There is nothing special that needs to be done to "control routi=
ng delays on data vs. WE".  Do you have any basis for that statement?

Using the method I described is absolutely the same as connecting up two 74=
X374 flip flops, nothing more, nothing less.  How is that a 'headache'?

Kevin Jennings

Article: 160211
Subject: Re: sram
From: rickman <gnuarm@gmail.com>
Date: Sun, 6 Aug 2017 14:00:20 -0400
Links: << >>  << T >>  << A >>
KJ wrote on 8/6/2017 1:40 PM:
> On Sunday, August 6, 2017 at 1:30:46 PM UTC-4, lasselangwad...@gmail.com wrote:
>> Den søndag den 6. august 2017 kl. 18.40.25 UTC+2 skrev rickman:
>>
>> and just using the clock give you the headache of trying to control routing
>> delays on data vs. WE
>>
>> using the dual edge output flipflop makes it all much controllable
>
> Not true.  There is nothing special that needs to be done to "control routing delays on data vs. WE".  Do you have any basis for that statement?

As long as the signals are register in the output FFs that's true.  But you 
can't register the clock!  So the routing delays will be *very* important if 
running a fast asynch SRAM.

If the dual edge output flipflops are used the clock can in fact be 
registers in essence giving all signals the same delays within a tolerance.


> Using the method I described is absolutely the same as connecting up two 74X374 flip flops, nothing more, nothing less.  How is that a 'headache'?

Huh?

-- 

Rick C

Article: 160212
Subject: Re: sram
From: rickman <gnuarm@gmail.com>
Date: Sun, 6 Aug 2017 14:07:32 -0400
Links: << >>  << T >>  << A >>
KJ wrote on 8/6/2017 1:33 PM:
> On Sunday, August 6, 2017 at 12:40:25 PM UTC-4, rickman wrote:
>> KJ wrote on 8/6/2017 8:01 AM:
>>> It's even easier than that to synchronously control a standard async SRAM.  Simply connect WE to the clock and hold OE active all the time except for cycles where you want to write something new into the SRAM.
>>
>> That would depend a *lot* on the details of the setup and hold times for the
>> async SRAM, no?  You can do what you want with data for much of the clock
>> cycle, but the address has to meet setup and hold for the entire WE time.
>> That's typically more than half a clock cycle and makes it hard to use it on
>> every clock cycle.
>>
> Address (and data) setup and hold times are easily met.  As a first order approximation, the setup time will be T/2-Tco(max).  The address hold time will be Tco(min).
>
> What is your source for statement "That's typically more than half a clock cycle"?  The ancient Cypress CY62256N lists both of these requirements (Tsa and Tha) as 0 ns [1].

I'm talking about the time the address must remain stable.  Your 
calculations above show it is at a minimum T/2.

When running with fast SRAM it can be very hard to get this to work 
properly.  The devil is in the details of the chips.


> The technique works.  You get single cycle read or write on 100% of the clock cycles, timing is met, period...and it worked 20+ years ago on product I designed [2].

Great!  You were able to use it on one device at an unknown speed.  What was 
the clock period?

Did you supply the WE from the external clock (same as to the FPGA) or a 
copy of the clock from inside the FPGA?  In the case of the former the total 
delay through the chip of the signals can be a significant part of the setup 
margin.  If the latter it is hard to control the routing delays.

-- 

Rick C

Article: 160213
Subject: Re: sram
From: lasselangwadtchristensen@gmail.com
Date: Sun, 6 Aug 2017 11:08:06 -0700 (PDT)
Links: << >>  << T >>  << A >>
Den s=C3=B8ndag den 6. august 2017 kl. 19.40.40 UTC+2 skrev KJ:
> On Sunday, August 6, 2017 at 1:30:46 PM UTC-4, lasselangwad...@gmail.com =
wrote:
> > Den s=C3=B8ndag den 6. august 2017 kl. 18.40.25 UTC+2 skrev rickman:
> >=20
> > and just using the clock give you the headache of trying to control rou=
ting=20
> > delays on data vs. WE=20
> >=20
> > using the dual edge output flipflop makes it all much controllable
>=20
> Not true.  There is nothing special that needs to be done to "control rou=
ting delays on data vs. WE".  Do you have any basis for that statement?

to get your clock out to you WE pin you first have to get off the clock net=
work and out to an IO, how are you going to guarantee that delay is the sam=
e as the data going from an output flop to an io?=20

>=20
> Using the method I described is absolutely the same as connecting up two =
74X374 flip flops, nothing more, nothing less.  How is that a 'headache'?
>=20

with a string of 374 you also have to make sure the delay on the clock is=
=20
controlled with regards to the data=20




Article: 160214
Subject: Re: sram
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 6 Aug 2017 12:26:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, August 6, 2017 at 2:08:09 PM UTC-4, lasselangwad...@gmail.com wr=
ote:
> Den s=C3=B8ndag den 6. august 2017 kl. 19.40.40 UTC+2 skrev KJ:
> > Not true.  There is nothing special that needs to be done to "control r=
outing delays on data vs. WE".  Do you have any basis for that statement?
>=20
> to get your clock out to you WE pin you first have to get off the clock n=
etwork and out to an IO, how are you going to guarantee that delay is the s=
ame as the data going from an output flop to an io?=20
>=20

One does not need to "guarantee that delay is the same as the data going fr=
om an output flop to an io" in order to get a working design as you stated.=
  Instead, one can design it such that the clock to the flip flops that gen=
erates the address/data/control signals are simultaneous, within some appli=
cable design tolerance, with the clock signal (aka WE) arriving at the SRAM=
.

In fact, since there are tolerances, if you design it such that the nominal=
 data delay matches the nominal clock delay as you suggest you are essentia=
lly crossing your fingers hoping that you don't run across a 'fast' data pa=
th and a 'slow' clock path over full PVT range...either that or you are len=
gthening the data path on the PCBA to guarantee that it never beats the clo=
ck.  Yes you can do that to get a guaranteed working design, but that would=
 seem to be more of the 'headache' that you mentioned than my approach of j=
ust routing them on the shortest path as one would probably normally do any=
way.

> >=20
> > Using the method I described is absolutely the same as connecting up tw=
o 74X374 flip flops, nothing more, nothing less.  How is that a 'headache'?
> >=20
>=20
> with a string of 374 you also have to make sure the delay on the clock is=
=20
> controlled with regards to the data

No.  The delay of data relative to clock in a string of flip flops is not i=
mportant at all if every flip flop receives the same rising edge.  Getting =
multiple receivers to receive the same clock signal (to within some toleran=
ce) is something that a designer does have control over.  Relying on the co=
ntrol of skew between two or more signals, not so much.

This simultaneous receipt of the clock signal is essentially what goes on i=
nside every FPGA.  You can send any FF output to the input of any other FF =
on the device because they design the clock network to produce this simulta=
neous action.  It's not because they added data routing delays.

Kevin Jennings

Article: 160215
Subject: Re: sram
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 6 Aug 2017 12:42:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, August 6, 2017 at 2:07:35 PM UTC-4, rickman wrote:
> KJ wrote on 8/6/2017 1:33 PM:
> > What is your source for statement "That's typically more than half a cl=
ock cycle"?  The ancient Cypress CY62256N lists both of these requirements =
(Tsa and Tha) as 0 ns [1].
>=20
> I'm talking about the time the address must remain stable.  Your=20
> calculations above show it is at a minimum T/2.
>=20

My calculation is T/2-Tco(max).  As long as Tco(max) <=3D T/2 then the desi=
gn will work with anything compatible with the Cypress part that I previous=
ly referenced that requires 0 setup time.  Tco(max) being less than one hal=
f of a clock cycle is not much of a hurdle.  The SRAM access time will typi=
cally be greater.

> When running with fast SRAM it can be very hard to get this to work=20
> properly.

Speaking for myself I can say that no it was not hard at all, it worked rig=
ht at the start.  I'm not sure where you see the difficulty.

>  The devil is in the details of the chips.
>=20
And I've provided the details.  More so than you.

> Great! =20
Thanks!

> You were able to use it on one device at an unknown speed.
You're making assumptions here that are incorrect.
 =20
> What was the clock period?
I dunno, that was 20+ years ago but it was using the fastest available CMOS=
 SRAMs of the mid to late 1990s.  But the clock speed is not relevant, the =
technique is still valid.  The biggest limiting factor is going to be the r=
ead/write speed of the async SRAM.

Kevin Jennings

Article: 160216
Subject: Re: sram
From: Richard Damon <Richard@Damon-Family.org>
Date: Sun, 6 Aug 2017 16:09:22 -0400
Links: << >>  << T >>  << A >>
On 8/6/17 3:42 PM, KJ wrote:
> On Sunday, August 6, 2017 at 2:07:35 PM UTC-4, rickman wrote:
>> KJ wrote on 8/6/2017 1:33 PM:
>>> What is your source for statement "That's typically more than half a clock cycle"?  The ancient Cypress CY62256N lists both of these requirements (Tsa and Tha) as 0 ns [1].
>>
>> I'm talking about the time the address must remain stable.  Your
>> calculations above show it is at a minimum T/2.
>>
> 
> My calculation is T/2-Tco(max).  As long as Tco(max) <= T/2 then the design will work with anything compatible with the Cypress part that I previously referenced that requires 0 setup time.  Tco(max) being less than one half of a clock cycle is not much of a hurdle.  The SRAM access time will typically be greater.
> 
>> When running with fast SRAM it can be very hard to get this to work
>> properly.
> 
> Speaking for myself I can say that no it was not hard at all, it worked right at the start.  I'm not sure where you see the difficulty.
> 
>>   The devil is in the details of the chips.
>>
> And I've provided the details.  More so than you.
> 
>> Great!
> Thanks!
> 
>> You were able to use it on one device at an unknown speed.
> You're making assumptions here that are incorrect.
>    
>> What was the clock period?
> I dunno, that was 20+ years ago but it was using the fastest available CMOS SRAMs of the mid to late 1990s.  But the clock speed is not relevant, the technique is still valid.  The biggest limiting factor is going to be the read/write speed of the async SRAM.
> 
> Kevin Jennings
> 

I think, if I understand what you are proposing, one big issue is you 
seem to be assuming that the clock that you are using as WE starts 
external to the FPGA (or at least comes out and goes back in) so that 
you know the clock rises before the data on the address bus can change. 
 From my experience, in very many cases, this is NOT true for an FPGA 
design, but some slower clock comes in, and the highest speed clocks are 
generated by PLLs in the FPGA.

A second really big issue is how do you do a read cycle if the write 
comes ungated from the clock. The best I can figure is you are assuming 
you can get a read done in 1/2 a clock cycle and just rewrite the data. 
In most such rams WE overrides OE, and the Selects kill both read and 
write. Unless you had a part with both a WE and WS (where WE could 
disable the WS, but did not itself need to have the required setup/hold 
to address) I can't see how you do reads with the clock anywhere close 
to cycle time, and having a WOM (Write only Memory) isn't that useful here.

Article: 160217
Subject: Re: sram
From: lasselangwadtchristensen@gmail.com
Date: Sun, 6 Aug 2017 13:09:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
Den s=C3=B8ndag den 6. august 2017 kl. 21.26.23 UTC+2 skrev KJ:
> On Sunday, August 6, 2017 at 2:08:09 PM UTC-4, lasselangwad...@gmail.com =
wrote:
> > Den s=C3=B8ndag den 6. august 2017 kl. 19.40.40 UTC+2 skrev KJ:
> > > Not true.  There is nothing special that needs to be done to "control=
 routing delays on data vs. WE".  Do you have any basis for that statement?
> >=20
> > to get your clock out to you WE pin you first have to get off the clock=
 network and out to an IO, how are you going to guarantee that delay is the=
 same as the data going from an output flop to an io?=20
> >=20
>=20
> One does not need to "guarantee that delay is the same as the data going =
from an output flop to an io" in order to get a working design as you state=
d.  Instead, one can design it such that the clock to the flip flops that g=
enerates the address/data/control signals are simultaneous, within some app=
licable design tolerance, with the clock signal (aka WE) arriving at the SR=
AM.


how are you going to control the delay from output ff to io vs, clock getti=
ng of the clock tree to io?=20

>=20
> In fact, since there are tolerances, if you design it such that the nomin=
al data delay matches the nominal clock delay as you suggest you are essent=
ially crossing your fingers hoping that you don't run across a 'fast' data =
path and a 'slow' clock path over full PVT range...either that or you are l=
engthening the data path on the PCBA to guarantee that it never beats the c=
lock.  Yes you can do that to get a guaranteed working design, but that wou=
ld seem to be more of the 'headache' that you mentioned than my approach of=
 just routing them on the shortest path as one would probably normally do a=
nyway.


using a DDR output data and WE all have the same path to io and should thus=
 track over PVT

using the clock directly is pretty much guranteed to add more delay than th=
e clock to out on the output ffs

>=20
> > >=20
> > > Using the method I described is absolutely the same as connecting up =
two 74X374 flip flops, nothing more, nothing less.  How is that a 'headache=
'?
> > >=20
> >=20
> > with a string of 374 you also have to make sure the delay on the clock =
is=20
> > controlled with regards to the data
>=20
> No.  The delay of data relative to clock in a string of flip flops is not=
 important at all if every flip flop receives the same rising edge.  Gettin=
g multiple receivers to receive the same clock signal (to within some toler=
ance) is something that a designer does have control over.  Relying on the =
control of skew between two or more signals, not so much.
>=20
> This simultaneous receipt of the clock signal is essentially what goes on=
 inside every FPGA.  You can send any FF output to the input of any other F=
F on the device because they design the clock network to produce this simul=
taneous action.  It's not because they added data routing delays.
>=20

FF out to FF in is safe by design, once you m mix in clock used as "data" y=
ou add an unknown delay



Article: 160218
Subject: Re: sram
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 6 Aug 2017 14:18:50 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, August 6, 2017 at 4:09:28 PM UTC-4, Richard Damon wrote:
> On 8/6/17 3:42 PM, KJ wrote:
> I think, if I understand what you are proposing, one big issue is you=20
> seem to be assuming that the clock that you are using as WE starts=20
> external to the FPGA (or at least comes out and goes back in) so that=20
> you know the clock rises before the data on the address bus can change.=
=20
>  From my experience, in very many cases, this is NOT true for an FPGA=20
> design, but some slower clock comes in, and the highest speed clocks are=
=20
> generated by PLLs in the FPGA.
>=20

No that was not my assumption.  The clocking situation is no different than=
 how one synchronizing the internal clock and the external clock in SDRAM o=
r DDR.  Even before there were DDR parts and DDR flops in FPGAs, there were=
 single clock SDRAMs and they had FPGA controllers.  Clock synchronization =
between the FPGA and the SDRAM is required there as well and would use the =
same control technique.

> In most such rams WE overrides OE, and the Selects kill both read and=20
> write.=20

Well, looking around now that does seem to be the case today which sort of =
makes me wonder which SRAM I was using back then.  At that time, CE and OE =
enabled the I/O drivers independent of WE.  Writing to memory was sometimes=
 (depending on the part) inhibited if OE was active.  I don't believe I rel=
ied on any bus-hold circuit circuit or any sort of other trickery like that=
.  I will say that the design did work and was in production for several ye=
ars without issue but, in any case, my solution does not seem applicable to=
day.  Interesting, good catch.

Kevin Jennings

Article: 160219
Subject: Re: sram
From: KJ <kkjennings@sbcglobal.net>
Date: Sun, 6 Aug 2017 14:32:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Sunday, August 6, 2017 at 4:09:31 PM UTC-4, lasselangwad...@gmail.com wrote:
> 
> how are you going to control the delay from output ff to io vs, clock getting of the clock tree to io? 
> 
By using the phase control of the PLL to adjust the clock leaving the chip relative to the clock internal to the chip.  That can be done in a way to guarantee operation.

> using a DDR output data and WE all have the same path to io and should 
> thus track over PVT

'Should' is an important word there...but practically speaking I agree that there is probably 'slim' chances of failure.

> FF out to FF in is safe by design, once you m mix in clock used as "data" 
> you add an unknown delay

Mixing in clock as data was not what I was doing.  In any case, based on my reply to Richard Damon's post, my approach, while it worked back in the day, wouldn't work now.

Kevin

Article: 160220
Subject: Re: sram
From: rickman <gnuarm@gmail.com>
Date: Sun, 6 Aug 2017 19:15:32 -0400
Links: << >>  << T >>  << A >>
KJ wrote on 8/6/2017 3:42 PM:
> On Sunday, August 6, 2017 at 2:07:35 PM UTC-4, rickman wrote:
>> KJ wrote on 8/6/2017 1:33 PM:
>>> What is your source for statement "That's typically more than half a clock cycle"?  The ancient Cypress CY62256N lists both of these requirements (Tsa and Tha) as 0 ns [1].
>>
>> I'm talking about the time the address must remain stable.  Your
>> calculations above show it is at a minimum T/2.
>>
>
> My calculation is T/2-Tco(max).  As long as Tco(max) <= T/2 then the design will work with anything compatible with the Cypress part that I previously referenced that requires 0 setup time.  Tco(max) being less than one half of a clock cycle is not much of a hurdle.  The SRAM access time will typically be greater.
>
>> When running with fast SRAM it can be very hard to get this to work
>> properly.
>
> Speaking for myself I can say that no it was not hard at all, it worked right at the start.  I'm not sure where you see the difficulty.
>
>>  The devil is in the details of the chips.
>>
> And I've provided the details.  More so than you.
>
>> Great!
> Thanks!
>
>> You were able to use it on one device at an unknown speed.
> You're making assumptions here that are incorrect.
>
>> What was the clock period?
> I dunno, that was 20+ years ago but it was using the fastest available CMOS SRAMs of the mid to late 1990s.  But the clock speed is not relevant, the technique is still valid.  The biggest limiting factor is going to be the read/write speed of the async SRAM.

Hmmm, looking at a current data sheet I don't see where you can gate the 
write cycle with OE.  WE, the byte enables and CE, but not OE.

-- 

Rick C

Article: 160221
Subject: Re: minimal HDMI pins to send video ?
From: Gabor <nospam@nospam.com>
Date: Mon, 7 Aug 2017 22:01:15 -0400
Links: << >>  << T >>  << A >>
On Friday, 8/4/2017 5:33 AM, abirov@gmail.com wrote:
> I am VHDL user , how to declare correctly :
> 
> i thought pixclk must be declare like this  :
> 
> reg pixclk;
> 
> clock instance_name (
>      .CLKIN_IN(clk100),
>      .CLKDV_OUT(pixclk),
>      .CLKFX_OUT(DCM_TMDS_CLKFX),
>      .CLKIN_IBUFG_OUT(clk_TMDS),
>      .CLK0_OUT(CLK0_OUT)
>      );
> 
> ERROR:HDLCompilers:246 - "asdf.v" line 48 Reference to scalar reg 'pixclk' is not a legal net lvalue
> ERROR:HDLCompilers:102 - "asdf.v" line 48 Connection to output port 'CLKDV_OUT' must be a net lvalue
> 

reg pixclk;

should be:

wire pixclk;

Compiler errors are a bit obtuse, but the idea is that a reg is
different from a wire in that it is meant to be assigned in a process
only.  A wire may only be assigned outside a process, in a continuous
assignment or port connection as in your code.  In SystemVerilog, you
can declare a signal as "logic" and then use it anywhere you like.

The above is simplified greatly.  I'd recommend a good book on Verilog,
but the only ones I'm familiar with are pretty much outdated.

-- 
Gabor

Article: 160222
Subject: SystemVerilog and alternatives
From: tullio <tullio.grassi@gmail.com>
Date: Tue, 8 Aug 2017 04:00:59 -0700 (PDT)
Links: << >>  << T >>  << A >>
Hello,

 i am an experienced FPGA designer, having used Verilog for long time.
For a mixed analog-digital project involving an ASIC and (maybe) an FPGA, i need to get ready for extensive verification and test-vector generation.
The mainstream tools seem to be SystemVerilog and UVM, which seem to have a difficult learning curve and also difficult maintenance.
But somebody suggested me to consider using Verilog and Python, having the advantage that they complement each other very nicely, and that Python is easy to learn.

Can anybody share experiences from real projects ?

Thanks,
  Tullio


Article: 160223
Subject: Re: sram
From: brimdavis@gmail.com
Date: Tue, 8 Aug 2017 17:37:04 -0700 (PDT)
Links: << >>  << T >>  << A >>
KJ wrote:
>
> It's even easier than that to synchronously control a standard async SRAM.  
> Simply connect WE to the clock and hold OE active all the time except 
> for cycles where you want to write something new into the SRAM.
>
As has been explained to you in detail by several other posters, your  method is not 'easier' with modern FPGA's and SRAMs.

The simplest way to get a high speed clock {gated or not} off the chip, coincident with other registered I/O signals, is to use the dual-edge IOB flip-flops as I suggested. 

The DDR technique I mentioned would run synchronous single-cycle read or write cycles at 50 MHz on a Spartan-3 Starter kit with an (IIRC) 10 ns SRAM, 66 MHz if using a duty-cycle-skewed clock to meet the WE pulse width requirements.

 Another advantage of the 'forwarding' method is that one can use the internal FPGA clock resources for clock multiply/divides etc. without needing to also manage the board-level low-skew clock distribution needed by your method.

-Brian

Article: 160224
Subject: SystemVerilog and alternatives
From: Darrin Nagy <darrin.nagy@gmail.com>
Date: Wed, 9 Aug 2017 01:21:18 -0700 (PDT)
Links: << >>  << T >>  << A >>
I have used cocotb to verify some modules recently. Fairly straightforward =
to get going and to write stimulators and checkers. There are some things I=
 didn't like (eg it deletes the work library and recompiles on every run) b=
ut it it uses make files to set up and run the sim so I found it easy to ha=
ck it to make it behave how I wanted.=20

I like to use python for algorithm development and modelling so it could no=
t be easier to reuse the model code in the python test bench.=20

My modules were in vhdl but it works with verilog.



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