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 160175

Article: 160175
Subject: Re: sram
From: kristoff <kristoff@skypro.be>
Date: Sat, 22 Jul 2017 20:32:47 +0200
Links: << >>  << T >>  << A >>
Hi Cecil,


Thanks for your reply.


I agree it's not a bulk-mode as such.

What I meant was that when doing multiple reads one after the other you 
can stich them together:


Correct me if I am wrong, but how I interprete the datasheets, the "read 
data from the address-bus" can be done at the same time as the "set next 
address on address-bus". This -I think- means you can "overlap" two 
concequative reads, resulting in one read per clock cycle.

At least, that is -I guess- what the "t OH" (Output Hold from Address 
Change) means in the "ready cycle(1)" timing waveform on page 7 of the 
datasheet).



But I do not see how (or if) something simular can be done for "write" 
operations, but perhaps I am missing something.




Kristoff




On 22-07-17 20:19, Cecil Bayona wrote:
> Static RAM chips do not have bulk mode, it's not needed, you write to it 
> one word at a time. Its EEPROM, FLASH, and similar memory with it's 
> complicated setup that are  in need of bulk mode as they are slow and 
> bulk mode is faster, some only have bulk mode.
> 
> 
> On 7/22/2017 12:52 PM, kristoff wrote:
>> Hi,
>>
>>
>> OK, left the lora chips asside for a while, so .. now back to FPGAs.
>>
>> I have two olimex ice40 boards where I would like to use the onboard 
>> SRAM. The RAM chip is a samsung K5R4016V1B-10 (256K words * 16 bits).
>>
>> The datasheets are here:
>> https://www.olimex.com/Products/_resources/ds_k6r4016v1d_rev40.pdf
>> The most important pages are page 7 (for "read"), pages 8 and 9 (for 
>> "write") and page 10 (for the functional description of the pins).
>>
>>
>> I am trying to interprete the datasheets to see how to use the chip. I 
>> think I understand how to read or write one word, but I still puzzled 
>> on how to do bulk-write transfers
>>
>>
>> * For read, it seams to be simple:
>> set /WE high and  /OE low (*)
>>
>> 1/ put the address on the address-bus
>> 2/ 10 ns later, read the data from the data-out
>> (*) ignoring the /CS, /LB and /UB pins to keep things simple.
>>
>> In bulk transfer, it is like this:
>> - set address 1 on the Address bus
>> - 10 ns later:
>> -> read the data of address 1 from data-out
>> -> (at the same time) set address 2 on the address bus
>> - 10 bs later:
>> -> read the data of address 2 from data-out
>> -> (at the same time) set address 3 on the address bus
>> (etc)
>>
>>
>> * For write, to write one single word, I think it goes like this
>>
>> 1/ set /WE low and /OE high to go to "write" mode
>> -> at the same time set te address on the address bus
>> -> do not yet put the data on the databus (as it still in "output" mode)
>> 2/ 10 ns later:
>> -> put the data on the data-bus (by then, the data-bus has switched to 
>> "data-in"
>> 3/ another 10 ns later:
>> -> set /WE high and /OE low to leave "write" mode
>>
>> But I am still puzzled on how to do a "bulk write" of data. The 
>> datasheets do not mention anything on what happens if leave the chip 
>> in "write" mode and just change the address on the address-bus (as is 
>> done for bulk-read)
>>
>> It there is no seperate bulk-write protocol, it looks like a write to 
>> the chip takes 3 times as much steps then a bulk-read (3 steps 
>> compaired to one single step).
>>
>>
>> Is this a correct interpretation of the datasheet?
>>
>> Can somebody who has already interfaced an FPGA with SRAM confirm or 
>> deny this. Or is there another trick on how to do a bulk-write on a 
>> SRAM chip?
>>
>>
>>
>>
>> Cheerio! Kr. Bonne.
> 
> 


Article: 160176
Subject: Re: sram
From: Richard Damon <Richard@Damon-Family.org>
Date: Sat, 22 Jul 2017 15:45:49 -0400
Links: << >>  << T >>  << A >>
This looks to be a fairly standard asynchronous static ram.

The basic requirement for a write cycle is that there is a Tas (Address 
stable) which the address bus must be stable before you can pull the WE 
line low, a Twp as the minimum length of time you can need to pull the 
WE signal low, and a Taw address hold you need to hold the address bus 
stable after WE goes high.

Sine Tas >= 0, and Taw >= 0, it is easy to think that you can just clock 
the WE signal on the same clock edge as the address, but that requires 
that the FPGA and the board layout has ZERO skew, which is basically 
impossible.

As you note, it is easy to read at full speed, cycle after cycle, you 
just need clock new addresses and one cycle later you can read the 
results. Note, this is not really a 'burst' operation, but just running 
full cycles one after the other (the burst terminology tend to imply 
there is some setup you do and after that you can read a given number of 
locations without needing to do the setup again).

For write with this sort of part there are several options:

1) Simplest, do every thing on rising edges and need 3 clock cycles to 
write, cycle 1, change address, cycle 2: drop we, cycle 3: Raise we and 
address hold.

2) Slightly more complicated, again do things on rising edges, but have 
something to delay the WE signal slightly. 2 Cycles, 1) Set Address, and 
with slight delay drop WE. 2) Hold address, and after a slight delay 
raise WE.

3) Instead of a slight delay in WE, drive WE on the falling edge of the 
clock, again 2 Cycles as above with the slight delay being the 1/2 cycle 
delay of the falling edge.

4) Discrete Pulse generation logic, have logic on the board with delay 
lines to generate the write pulse, so that WE will pulse low shortly 
after the address is stable, and comes back high shortly before the 
address might change again. This lets you do a write every cycle.

5) Like the Discrete Pulse Generation, but in the FPGA using a higher 
speed clock. If you can be sure that the WE pulse is faster or slower 
than the address bus (including FPGA skew), you could use a 400-500 MHz 
clock and create a 7.5/8 ns pulse on WE. If you can enforce that, you 
can use a 700 MHz clock and generate a 5 clock cycle pulse (7.14ns) in 
the middle of the 10 ns cycle.

This is one of the limitations of asynchronous rams, write cycles take 
more 'edges' to perform. Thus either needing more cycles or something to 
generate higher speed edges.


On 7/22/17 1:52 PM, kristoff wrote:
> Hi,
> 
> 
> OK, left the lora chips asside for a while, so .. now back to FPGAs.
> 
> I have two olimex ice40 boards where I would like to use the onboard 
> SRAM. The RAM chip is a samsung K5R4016V1B-10 (256K words * 16 bits).
> 
> The datasheets are here:
> https://www.olimex.com/Products/_resources/ds_k6r4016v1d_rev40.pdf
> The most important pages are page 7 (for "read"), pages 8 and 9 (for 
> "write") and page 10 (for the functional description of the pins).
> 
> 
> I am trying to interprete the datasheets to see how to use the chip. I 
> think I understand how to read or write one word, but I still puzzled on 
> how to do bulk-write transfers
> 
> 
> * For read, it seams to be simple:
> set /WE high and  /OE low (*)
> 
> 1/ put the address on the address-bus
> 2/ 10 ns later, read the data from the data-out
> (*) ignoring the /CS, /LB and /UB pins to keep things simple.
> 
> In bulk transfer, it is like this:
> - set address 1 on the Address bus
> - 10 ns later:
> -> read the data of address 1 from data-out
> -> (at the same time) set address 2 on the address bus
> - 10 bs later:
> -> read the data of address 2 from data-out
> -> (at the same time) set address 3 on the address bus
> (etc)
> 
> 
> * For write, to write one single word, I think it goes like this
> 
> 1/ set /WE low and /OE high to go to "write" mode
> -> at the same time set te address on the address bus
> -> do not yet put the data on the databus (as it still in "output" mode)
> 2/ 10 ns later:
> -> put the data on the data-bus (by then, the data-bus has switched to 
> "data-in"
> 3/ another 10 ns later:
> -> set /WE high and /OE low to leave "write" mode
> 
> But I am still puzzled on how to do a "bulk write" of data. The 
> datasheets do not mention anything on what happens if leave the chip in 
> "write" mode and just change the address on the address-bus (as is done 
> for bulk-read)
> 
> It there is no seperate bulk-write protocol, it looks like a write to 
> the chip takes 3 times as much steps then a bulk-read (3 steps compaired 
> to one single step).
> 
> 
> Is this a correct interpretation of the datasheet?
> 
> Can somebody who has already interfaced an FPGA with SRAM confirm or 
> deny this. Or is there another trick on how to do a bulk-write on a SRAM 
> chip?
> 
> 
> 
> 
> Cheerio! Kr. Bonne.


Article: 160177
Subject: Re: sram
From: lasselangwadtchristensen@gmail.com
Date: Sat, 22 Jul 2017 12:56:05 -0700 (PDT)
Links: << >>  << T >>  << A >>
Den l=C3=B8rdag den 22. juli 2017 kl. 20.32.52 UTC+2 skrev kristoff:
> Hi Cecil,
>=20
>=20
> Thanks for your reply.
>=20
>=20
> I agree it's not a bulk-mode as such.
>=20
> What I meant was that when doing multiple reads one after the other you=
=20
> can stich them together:
>=20
>=20
> Correct me if I am wrong, but how I interprete the datasheets, the "read=
=20
> data from the address-bus" can be done at the same time as the "set next=
=20
> address on address-bus". This -I think- means you can "overlap" two=20
> concequative reads, resulting in one read per clock cycle.

SRAM doesn't have a clock, you just have to comply with the required timing

>=20
> At least, that is -I guess- what the "t OH" (Output Hold from Address=20
> Change) means in the "ready cycle(1)" timing waveform on page 7 of the=20
> datasheet).
>=20
>=20
>=20
> But I do not see how (or if) something simular can be done for "write"=20
> operations, but perhaps I am missing something.
>=20

write happens on the rising edge on /WR

-Lasse


Article: 160178
Subject: Re: sram
From: Richard Damon <Richard@Damon-Family.org>
Date: Sat, 22 Jul 2017 16:23:07 -0400
Links: << >>  << T >>  << A >>
On 7/22/17 3:56 PM, lasselangwadtchristensen@gmail.com wrote:
> Den lørdag den 22. juli 2017 kl. 20.32.52 UTC+2 skrev kristoff:
>> Hi Cecil,
>>
>>
>> Thanks for your reply.
>>
>>
>> I agree it's not a bulk-mode as such.
>>
>> What I meant was that when doing multiple reads one after the other you
>> can stich them together:
>>
>>
>> Correct me if I am wrong, but how I interprete the datasheets, the "read
>> data from the address-bus" can be done at the same time as the "set next
>> address on address-bus". This -I think- means you can "overlap" two
>> concequative reads, resulting in one read per clock cycle.
> 
> SRAM doesn't have a clock, you just have to comply with the required timing
> 
>>
>> At least, that is -I guess- what the "t OH" (Output Hold from Address
>> Change) means in the "ready cycle(1)" timing waveform on page 7 of the
>> datasheet).
>>
>>
>>
>> But I do not see how (or if) something simular can be done for "write"
>> operations, but perhaps I am missing something.
>>
> 
> write happens on the rising edge on /WR
> 
> -Lasse
> 

Actually, with asynchronous parts, things don't happen 'on edges' but on 
levels (you measure timing requirements edge to edge). Asynchronous 
Srams tend to be a sea of RS Flip flops, and when write is low, the 
addresses flip flops will have their set or reset line asserted, so if 
you wanted to talk of a time when the write happened, it was on the 
falling edge, with a propagation delay/hold requirement.

Toh is the minimum guaranteed propagation delay from address to data, 
just like Taa is the maximum delay from address to data. (Trc actually 
isn't a critical parameter for the ram itself, but is a nominal system 
parameter. With Asyncronuous SRam, changing the address inputs faster 
than Trc won't cause any problems, except for the fact that you won't 
get valid data out until you stop doing it.

Article: 160179
Subject: Re: sram
From: kristoff <kristoff@skypro.be>
Date: Sun, 23 Jul 2017 01:46:08 +0200
Links: << >>  << T >>  << A >>
Hi Richard,


Thank you for your reply.

Your message really helped to better understand the timing waveforms.


I'll start with the simpest setup and after that experiment with using 
the falling edge of the clock to clear the /WE signal (option 3).



Kristoff



Article: 160180
Subject: Re: sram
From: Richard Damon <Richard@Damon-Family.org>
Date: Sat, 22 Jul 2017 20:34:16 -0400
Links: << >>  << T >>  << A >>
On 7/22/17 7:46 PM, kristoff wrote:
> Hi Richard,
> 
> 
> Thank you for your reply.
> 
> Your message really helped to better understand the timing waveforms.
> 
> 
> I'll start with the simpest setup and after that experiment with using 
> the falling edge of the clock to clear the /WE signal (option 3).
> 
> 
> 
> Kristoff
> 
> 

One thing to remind about, having a 10ns memory part does NOT mean you 
can talk to it with a 100MHz (10ns) clock. You will need to add in time 
from Clock->output on your address bus, and the needed Setup time on the 
data bus in. If you want the best performance, if possible you want both 
of these to be using FF in the I/O block of the FPGA, as those will have 
much lower propagation delays.

Asynchronous devices can be harder to use, but can give you 
significantly improved read performance if you are worried about 
latency, as synchronous interfaces can cost clock cycle. (on the other 
hand, synchronous interfaces can often write faster as you can often 
just stream the data, and the latency isn't important).

Article: 160181
Subject: Re: sram
From: rickman <gnuarm@gmail.com>
Date: Mon, 24 Jul 2017 02:18:13 -0400
Links: << >>  << T >>  << A >>
Richard Damon wrote on 7/22/2017 4:23 PM:
> On 7/22/17 3:56 PM, lasselangwadtchristensen@gmail.com wrote:
>> Den lørdag den 22. juli 2017 kl. 20.32.52 UTC+2 skrev kristoff:
>>> Hi Cecil,
>>>
>>>
>>> Thanks for your reply.
>>>
>>>
>>> I agree it's not a bulk-mode as such.
>>>
>>> What I meant was that when doing multiple reads one after the other you
>>> can stich them together:
>>>
>>>
>>> Correct me if I am wrong, but how I interprete the datasheets, the "read
>>> data from the address-bus" can be done at the same time as the "set next
>>> address on address-bus". This -I think- means you can "overlap" two
>>> concequative reads, resulting in one read per clock cycle.
>>
>> SRAM doesn't have a clock, you just have to comply with the required timing
>>
>>>
>>> At least, that is -I guess- what the "t OH" (Output Hold from Address
>>> Change) means in the "ready cycle(1)" timing waveform on page 7 of the
>>> datasheet).
>>>
>>>
>>>
>>> But I do not see how (or if) something simular can be done for "write"
>>> operations, but perhaps I am missing something.
>>>
>>
>> write happens on the rising edge on /WR
>>
>> -Lasse
>>
>
> Actually, with asynchronous parts, things don't happen 'on edges' but on
> levels (you measure timing requirements edge to edge). Asynchronous Srams
> tend to be a sea of RS Flip flops, and when write is low, the addresses flip
> flops will have their set or reset line asserted, so if you wanted to talk
> of a time when the write happened, it was on the falling edge, with a
> propagation delay/hold requirement.
>
> Toh is the minimum guaranteed propagation delay from address to data, just
> like Taa is the maximum delay from address to data. (Trc actually isn't a
> critical parameter for the ram itself, but is a nominal system parameter.
> With Asyncronuous SRam, changing the address inputs faster than Trc won't
> cause any problems, except for the fact that you won't get valid data out
> until you stop doing it.

I think what Richard wrote is the clearest explanation of why there is no 
bulk write with async RAM.  The level of the AND of WR- and CS-.  So while 
these two signals are low it is expected the address does *not* change.  If 
the address changed, the RAM cell selected will change and there can be 
extraneous cells selected as the address lines settle.  By writing to 
location 3 and then 4 without removing WR or CS you can be writing to any 
combination of 0 to 7 in the switch.  Since none of this meets timing the 
writing will be random garbage and not even the data you are trying to write 
to locations 3 and 4.

When both WR and CS are asserted, keep the address stable and keep the data 
stable for the last N ns before either control line is deasserted.

-- 

Rick C

Article: 160182
Subject: Re: sram
From: Mike Perkins <spam@spam.com>
Date: Sat, 29 Jul 2017 20:32:09 +0100
Links: << >>  << T >>  << A >>
On 22/07/2017 20:56, lasselangwadtchristensen@gmail.com wrote:
> Den lørdag den 22. juli 2017 kl. 20.32.52 UTC+2 skrev kristoff:
>> Hi Cecil,
>>
>>
>> Thanks for your reply.
>>
>>
>> I agree it's not a bulk-mode as such.
>>
>> What I meant was that when doing multiple reads one after the other you
>> can stich them together:
>>
>>
>> Correct me if I am wrong, but how I interprete the datasheets, the "read
>> data from the address-bus" can be done at the same time as the "set next
>> address on address-bus". This -I think- means you can "overlap" two
>> concequative reads, resulting in one read per clock cycle.
>
> SRAM doesn't have a clock, you just have to comply with the required timing

There are some forms of clocked SRAM. ZBT was one type introduced by IDT.

I assume it still exists?


-- 
Mike Perkins
Video Solutions Ltd
www.videosolutions.ltd.uk

Article: 160183
Subject: Re: sram
From: Richard Damon <Richard@Damon-Family.org>
Date: Sat, 29 Jul 2017 18:06:31 -0400
Links: << >>  << T >>  << A >>
On 7/29/17 3:32 PM, Mike Perkins wrote:
> On 22/07/2017 20:56, lasselangwadtchristensen@gmail.com wrote:
>> Den lørdag den 22. juli 2017 kl. 20.32.52 UTC+2 skrev kristoff:
>>> Hi Cecil,
>>>
>>>
>>> Thanks for your reply.
>>>
>>>
>>> I agree it's not a bulk-mode as such.
>>>
>>> What I meant was that when doing multiple reads one after the other you
>>> can stich them together:
>>>
>>>
>>> Correct me if I am wrong, but how I interprete the datasheets, the "read
>>> data from the address-bus" can be done at the same time as the "set next
>>> address on address-bus". This -I think- means you can "overlap" two
>>> concequative reads, resulting in one read per clock cycle.
>>
>> SRAM doesn't have a clock, you just have to comply with the required 
>> timing
> 
> There are some forms of clocked SRAM. ZBT was one type introduced by IDT.
> 
> I assume it still exists?
> 
> 

The datasheet pointed to was a classical Asynchronous Static Ram, which 
doesn't have a clock.

There ARE Synchronous Static Rams which do have a clock pin. Synchronous 
devices tend to be a bit easier to interface to a synchronous systems, 
which most FPGA systems tend to be. Sometimes you lose a bit in latency 
when using them though.

Article: 160184
Subject: Re: sram
From: rickman <gnuarm@gmail.com>
Date: Sun, 30 Jul 2017 23:26:37 -0400
Links: << >>  << T >>  << A >>
Richard Damon wrote on 7/29/2017 6:06 PM:
> On 7/29/17 3:32 PM, Mike Perkins wrote:
>> On 22/07/2017 20:56, lasselangwadtchristensen@gmail.com wrote:
>>> Den lørdag den 22. juli 2017 kl. 20.32.52 UTC+2 skrev kristoff:
>>>> Hi Cecil,
>>>>
>>>>
>>>> Thanks for your reply.
>>>>
>>>>
>>>> I agree it's not a bulk-mode as such.
>>>>
>>>> What I meant was that when doing multiple reads one after the other you
>>>> can stich them together:
>>>>
>>>>
>>>> Correct me if I am wrong, but how I interprete the datasheets, the "read
>>>> data from the address-bus" can be done at the same time as the "set next
>>>> address on address-bus". This -I think- means you can "overlap" two
>>>> concequative reads, resulting in one read per clock cycle.
>>>
>>> SRAM doesn't have a clock, you just have to comply with the required timing
>>
>> There are some forms of clocked SRAM. ZBT was one type introduced by IDT.
>>
>> I assume it still exists?
>>
>>
>
> The datasheet pointed to was a classical Asynchronous Static Ram, which
> doesn't have a clock.
>
> There ARE Synchronous Static Rams which do have a clock pin. Synchronous
> devices tend to be a bit easier to interface to a synchronous systems, which
> most FPGA systems tend to be. Sometimes you lose a bit in latency when using
> them though.

I don't know the details of how SRAM is constructed, but there was a strong 
market for it until maybe about 10 years ago.  Then growth of SRAM sizes 
pretty much stopped as new devices dwindled.  DRAM has continued to improve 
at the cutting edge of semiconductor technology along with Flash, but SRAM 
is now the red headed stepchild.  I guess the functionality of SRAM has 
largely been incorporated internally in FPGAs.  If more size is needed than 
is convenient in FPGAs, DRAM is used.  They may have longer latency, but 
speed is certainly not lacking.

-- 

Rick C

Article: 160185
Subject: Re: sram
From: David Brown <david.brown@hesbynett.no>
Date: Mon, 31 Jul 2017 08:42:15 +0200
Links: << >>  << T >>  << A >>
On 31/07/17 05:26, rickman wrote:
> Richard Damon wrote on 7/29/2017 6:06 PM:
>> On 7/29/17 3:32 PM, Mike Perkins wrote:
>>> On 22/07/2017 20:56, lasselangwadtchristensen@gmail.com wrote:
>>>> Den lørdag den 22. juli 2017 kl. 20.32.52 UTC+2 skrev kristoff:
>>>>> Hi Cecil,
>>>>>
>>>>>
>>>>> Thanks for your reply.
>>>>>
>>>>>
>>>>> I agree it's not a bulk-mode as such.
>>>>>
>>>>> What I meant was that when doing multiple reads one after the other
>>>>> you
>>>>> can stich them together:
>>>>>
>>>>>
>>>>> Correct me if I am wrong, but how I interprete the datasheets, the
>>>>> "read
>>>>> data from the address-bus" can be done at the same time as the "set
>>>>> next
>>>>> address on address-bus". This -I think- means you can "overlap" two
>>>>> concequative reads, resulting in one read per clock cycle.
>>>>
>>>> SRAM doesn't have a clock, you just have to comply with the required
>>>> timing
>>>
>>> There are some forms of clocked SRAM. ZBT was one type introduced by
>>> IDT.
>>>
>>> I assume it still exists?
>>>
>>>
>>
>> The datasheet pointed to was a classical Asynchronous Static Ram, which
>> doesn't have a clock.
>>
>> There ARE Synchronous Static Rams which do have a clock pin. Synchronous
>> devices tend to be a bit easier to interface to a synchronous systems,
>> which
>> most FPGA systems tend to be. Sometimes you lose a bit in latency when
>> using
>> them though.
> 
> I don't know the details of how SRAM is constructed, but there was a
> strong market for it until maybe about 10 years ago.  Then growth of
> SRAM sizes pretty much stopped as new devices dwindled.  DRAM has
> continued to improve at the cutting edge of semiconductor technology
> along with Flash, but SRAM is now the red headed stepchild.  I guess the
> functionality of SRAM has largely been incorporated internally in
> FPGAs.  If more size is needed than is convenient in FPGAs, DRAM is
> used.  They may have longer latency, but speed is certainly not lacking.
> 

Roughly speaking, DRAM needs one transistor and a capacitor for a cell -
SRAM needs more transistors (4, I think).  So SRAM costs a good deal
more per bit than DRAM.  Once speeds reached the point where bus speeds
were the limiting factor for throughput rather than the memory speed,
and after DRAM started having internal refresh rather than external
refresh (needing active read/re-write cycles from the memory
controller), DRAM was almost as fast as SRAM but much cheaper.  SRAM
still wins out on latency (and lower standby power), but as you say the
SRAM has moved on board on devices (FPGAs, caches in processors, on-chip
ram in microcontrollers) for even lower latency.



Article: 160186
Subject: Re: sram
From: brimdavis@gmail.com
Date: Tue, 1 Aug 2017 16:21:27 -0700 (PDT)
Links: << >>  << T >>  << A >>
kristoff wrote:
> 
> I'll start with the simpest setup and after that experiment with using 
> the falling edge of the clock to clear the /WE signal (option 3).
> 
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

That S3 example code can be found here:
  https://sites.google.com/site/fpgastuff/ram_test.zip

The dual-edge I/O primitive for the ICE family would be SB_IO or SB_IO_OD, see:
 https://www.latticesemi.com/~/media/latticesemi/documents/technicalbriefs/sbticetechnologylibrary201701.pdf

-Brian

Article: 160187
Subject: Alternative for LUT?
From: Borneq <borneq@antyspam.hidden.pl>
Date: Wed, 2 Aug 2017 23:12:44 +0200
Links: << >>  << T >>  << A >>
I saw http://ijgti.org.in/index.php/ijgti/article/view/116
but haven't contact with IJGTI.

Article: 160188
Subject: What kit for SPARTAN-3?
From: Borneq <borneq@antyspam.hidden.pl>
Date: Wed, 2 Aug 2017 23:32:25 +0200
Links: << >>  << T >>  << A >>
I have
XILINX - XC3S4000 - 4FGG676I - SPARTAN-3 FPGA 4M STD 676-FBGA
someone advise me XC6SLX9

Article: 160189
Subject: minimal HDMI pins to send video ?
From: abirov@gmail.com
Date: Thu, 3 Aug 2017 03:49:47 -0700 (PDT)
Links: << >>  << T >>  << A >>
Dear all 

who knows 4 pairs of 

1)  CLOCK+, CLOCK-
2)  TMDS2+, TMDS2-
3)  TMDS1+, TMDS1-
4)  TMDS0+, TMDS0-

are enough to send video by HDMI or need to generate some other signals ?

Article: 160190
Subject: Re: minimal HDMI pins to send video ?
From: Richard.Damon@f10.n1.z8.fidonet.org (Richard Damon)
Date: Thu, 03 Aug 2017 22:59:44 +1200
Links: << >>  << T >>  << A >>
>From Newsgroup: comp.arch.fpga

On 8/3/17 12:50 PM, Jecel wrote:
> On Thursday, August 3, 2017 at 7:49:53 AM UTC-3, abi...@gmail.com wrote:
>> Dear all
>>
>> who knows 4 pairs of
>>
>> 1)  CLOCK+, CLOCK-
>> 2)  TMDS2+, TMDS2-
>> 3)  TMDS1+, TMDS1-
>> 4)  TMDS0+, TMDS0-
>>
>> are enough to send video by HDMI or need to generate some other signals ?
> 
> I thought an I2C interface would also be needed, but it seems not:
> 
> http://www.fpga4fun.com/HDMI.html
> 
> -- Jecel
> 

The I2C bus is to provide capability information about the display to 
the controller (it is often just a simple I2C rom). If the transmitter 
already knows how it is going to send (or is configured by the user) it 
doesn't need to send anything on the I2C bus.
SEEN-BY: 1/5 10 101 102 122 126 134 186 2/122 195/0 1


Article: 160191
Subject: Re: minimal HDMI pins to send video ?
From: abirov@f10.n1.z10.fidonet.org (abirov)
Date: Fri, 04 Aug 2017 02:33:09 +1200
Links: << >>  << T >>  << A >>
>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


Article: 160192
Subject: Re: minimal HDMI pins to send video ?
From: abirov@gmail.com
Date: Thu, 3 Aug 2017 08:29:46 -0700 (PDT)
Links: << >>  << T >>  << A >>
 
 1)  CLOCK+, CLOCK-
 2)  TMDS2+, TMDS2-
 3)  TMDS1+, TMDS1-
 4)  TMDS0+, TMDS0-
 
 5) GND connected to pins (2,5,8,11,17,pins or connector housing)


Article: 160193
Subject: Re: minimal HDMI pins to send video ?
From: abirov@gmail.com
Date: Thu, 3 Aug 2017 08:41:16 -0700 (PDT)
Links: << >>  << T >>  << A >>
and ground connected to 2,5,8,11,17 pins and housing.

Article: 160194
Subject: Re: minimal HDMI pins to send video ?
From: Jecel <jecel@merlintec.com>
Date: Thu, 3 Aug 2017 09:50:32 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, August 3, 2017 at 7:49:53 AM UTC-3, abi...@gmail.com wrote:
> Dear all 
> 
> who knows 4 pairs of 
> 
> 1)  CLOCK+, CLOCK-
> 2)  TMDS2+, TMDS2-
> 3)  TMDS1+, TMDS1-
> 4)  TMDS0+, TMDS0-
> 
> are enough to send video by HDMI or need to generate some other signals ?

I thought an I2C interface would also be needed, but it seems not:

http://www.fpga4fun.com/HDMI.html

-- Jecel

Article: 160195
Subject: Re: minimal HDMI pins to send video ?
From: Jecel <jecel@merlintec.com>
Date: Thu, 3 Aug 2017 09:52:30 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Thursday, August 3, 2017 at 7:49:53 AM UTC-3, abi...@gmail.com wrote:
> Dear all 
> 
> who knows 4 pairs of 
> 
> 1)  CLOCK+, CLOCK-
> 2)  TMDS2+, TMDS2-
> 3)  TMDS1+, TMDS1-
> 4)  TMDS0+, TMDS0-
> 
> are enough to send video by HDMI or need to generate some other signals ?

http://www.fpga4fun.com/HDMI.html shows examples with just those 8 FPGA pins

Article: 160196
Subject: Re: minimal HDMI pins to send video ?
From: Richard Damon <Richard@Damon-Family.org>
Date: Thu, 3 Aug 2017 22:59:44 -0400
Links: << >>  << T >>  << A >>
On 8/3/17 12:50 PM, Jecel wrote:
> On Thursday, August 3, 2017 at 7:49:53 AM UTC-3, abi...@gmail.com wrote:
>> Dear all
>>
>> who knows 4 pairs of
>>
>> 1)  CLOCK+, CLOCK-
>> 2)  TMDS2+, TMDS2-
>> 3)  TMDS1+, TMDS1-
>> 4)  TMDS0+, TMDS0-
>>
>> are enough to send video by HDMI or need to generate some other signals ?
> 
> I thought an I2C interface would also be needed, but it seems not:
> 
> http://www.fpga4fun.com/HDMI.html
> 
> -- Jecel
> 

The I2C bus is to provide capability information about the display to 
the controller (it is often just a simple I2C rom). If the transmitter 
already knows how it is going to send (or is configured by the user) it 
doesn't need to send anything on the I2C bus.

Article: 160197
Subject: Re: minimal HDMI pins to send video ?
From: gtwrek@f10.n1.z26.fidonet.org (gtwrek)
Date: Fri, 04 Aug 2017 20:49:55 +1200
Links: << >>  << T >>  << A >>
>From Newsgroup: comp.arch.fpga

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
SEEN-BY: 1/5 10 101 102 122 126 134 186 2/122 195/0 1


Article: 160198
Subject: Re: minimal HDMI pins to send video ?
From: abirov@gmail.com
Date: Fri, 4 Aug 2017 02:33:09 -0700 (PDT)
Links: << >>  << T >>  << A >>
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

Article: 160199
Subject: Re: minimal HDMI pins to send video ?
From: abirov@f10.n1.z28.fidonet.org (abirov)
Date: Fri, 04 Aug 2017 22:05:55 +1200
Links: << >>  << T >>  << A >>
>From Newsgroup: comp.arch.fpga

Thank you it works !
SEEN-BY: 1/5 10 101 102 122 126 134 186 2/122 195/0 1




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