Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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
Den onsdag den 21. juni 2017 kl. 14.08.53 UTC+2 skrev Rick C. Hodgin: > I've been given conflicting device on which language to use. There > are people I would consider to be expert professionals who tell me > to use VHDL, and others who tell me Verilog. Most everybody tells > me that if I use VHDL there's less chance for error, but that it > does take more effort to learn. > > Any thoughts? > don't you already have enough arguments over religion? ;)Article: 160151
lasselangwadtchristensen@gmail.com wrote on 6/21/2017 5:05 PM: > Den onsdag den 21. juni 2017 kl. 14.08.53 UTC+2 skrev Rick C. Hodgin: >> I've been given conflicting device on which language to use. There >> are people I would consider to be expert professionals who tell me >> to use VHDL, and others who tell me Verilog. Most everybody tells >> me that if I use VHDL there's less chance for error, but that it >> does take more effort to learn. >> >> Any thoughts? >> > > don't you already have enough arguments over religion? ;) I feel that is uncalled for. When he comes here proselytizing then respond about that (or better ignore him). But when he comes here like the rest of us asking for technical help, why pick on him? -- Rick CArticle: 160152
On Wednesday, June 21, 2017 at 5:05:50 PM UTC-4, lasselangwad...@gmail.com wrote: > Den onsdag den 21. juni 2017 kl. 14.08.53 UTC+2 skrev Rick C. Hodgin: > > I've been given conflicting device on which language to use. There > > are people I would consider to be expert professionals who tell me > > to use VHDL, and others who tell me Verilog. Most everybody tells > > me that if I use VHDL there's less chance for error, but that it > > does take more effort to learn. > > > > Any thoughts? > > don't you already have enough arguments over religion? ;) LOL! I didn't know. I plea ignorance. Thank you, Rick C. HodginArticle: 160153
On Wednesday, June 21, 2017 at 5:17:24 PM UTC-4, rickman wrote: > lasselangwadtchristensen@gmail.com wrote on 6/21/2017 5:05 PM: > > Den onsdag den 21. juni 2017 kl. 14.08.53 UTC+2 skrev Rick C. Hodgin: > >> I've been given conflicting device on which language to use. There > >> are people I would consider to be expert professionals who tell me > >> to use VHDL, and others who tell me Verilog. Most everybody tells > >> me that if I use VHDL there's less chance for error, but that it > >> does take more effort to learn. > >> > >> Any thoughts? > >> > > > > don't you already have enough arguments over religion? ;) > > I feel that is uncalled for. When he comes here proselytizing then respond > about that (or better ignore him). But when he comes here like the rest of > us asking for technical help, why pick on him? It's okay. I thought it was very funny actually. I couldn't respond more timely though because I was at a stop light when I read it. :-) Thank you, Rick C. HodginArticle: 160154
Rick C. Hodgin wrote on 6/21/2017 5:28 PM: > On Wednesday, June 21, 2017 at 5:17:24 PM UTC-4, rickman wrote: >> lasselangwadtchristensen@gmail.com wrote on 6/21/2017 5:05 PM: >>> Den onsdag den 21. juni 2017 kl. 14.08.53 UTC+2 skrev Rick C. Hodgin: >>>> I've been given conflicting device on which language to use. There >>>> are people I would consider to be expert professionals who tell me >>>> to use VHDL, and others who tell me Verilog. Most everybody tells >>>> me that if I use VHDL there's less chance for error, but that it >>>> does take more effort to learn. >>>> >>>> Any thoughts? >>>> >>> >>> don't you already have enough arguments over religion? ;) >> >> I feel that is uncalled for. When he comes here proselytizing then respond >> about that (or better ignore him). But when he comes here like the rest of >> us asking for technical help, why pick on him? > > It's okay. I thought it was very funny actually. I couldn't > respond more timely though because I was at a stop light when > I read it. :-) Actually I guess it was rather a joke instead of an insult. I didn't pick up on that. VHDL vs. Verilog can very much be a religious war. Sorry Lasse. -- Rick CArticle: 160155
Den onsdag den 21. juni 2017 kl. 23.17.24 UTC+2 skrev rickman: > lasselangwadtchristensen@gmail.com wrote on 6/21/2017 5:05 PM: > > Den onsdag den 21. juni 2017 kl. 14.08.53 UTC+2 skrev Rick C. Hodgin: > >> I've been given conflicting device on which language to use. There > >> are people I would consider to be expert professionals who tell me > >> to use VHDL, and others who tell me Verilog. Most everybody tells > >> me that if I use VHDL there's less chance for error, but that it > >> does take more effort to learn. > >> > >> Any thoughts? > >> > > > > don't you already have enough arguments over religion? ;) > > I feel that is uncalled for. When he comes here proselytizing then respond > about that (or better ignore him). But when he comes here like the rest of > us asking for technical help, why pick on him? if you think is was picking on him that's on you, it was meant as a tongue-in-cheeck comment that asking whether you should use verilog or vhdl is probably going to end like asking what religion is best catholic or protestant. Everyone has a set opinion and soon someone will say you shouldn't be either and be atheist insteadArticle: 160156
On Wednesday, June 21, 2017 at 5:42:40 PM UTC-4, lasselangwad...@gmail.com wrote: > Den onsdag den 21. juni 2017 kl. 23.17.24 UTC+2 skrev rickman: > > lasselangwadtchristensen@gmail.com wrote on 6/21/2017 5:05 PM: > > > Den onsdag den 21. juni 2017 kl. 14.08.53 UTC+2 skrev Rick C. Hodgin: > > >> I've been given conflicting device on which language to use. There > > >> are people I would consider to be expert professionals who tell me > > >> to use VHDL, and others who tell me Verilog. Most everybody tells > > >> me that if I use VHDL there's less chance for error, but that it > > >> does take more effort to learn. > > >> > > >> Any thoughts? > > >> > > > > > > don't you already have enough arguments over religion? ;) > > > > I feel that is uncalled for. When he comes here proselytizing then respond > > about that (or better ignore him). But when he comes here like the rest of > > us asking for technical help, why pick on him? > > if you think is was picking on him that's on you, it was meant as a > tongue-in-cheeck comment that asking whether you should use verilog or vhdl > is probably going to end like asking what religion is best catholic or protestant. Everyone has a set opinion and soon someone will say you shouldn't > be either and be atheist instead Just so everybody's clear also ... I enjoy working with people, and sharing in our technical expertise. My posts about salvation and forgiveness of sin are given because of what's happened in my life. I'm currently part of a group of people who are from all backgrounds and interests, with some of them overlapping into the same hardware and software areas I'm interested in. As such, it's a very powerful and diverse group of people. It's the thing I enjoy ... helping, sharing, expressing, in these areas. We are together a more diverse and capable group than we are in iso- lation. Thank you, Rick C. HodginArticle: 160157
Rick, Most of the hard things related to conversions and types are summarized in: http://synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf Cheers, JimArticle: 160158
Jim Lewis wrote: > Rick, Most of the hard things related to conversions and > types are summarized in: > http://synthworks.com/papers/vhdl_math_tricks_mapld_2003.pdf > > Cheers, Jim Thanks, Jim. I'll check it out. Thank you, Rick C. HodginArticle: 160159
Rick C. Hodgin wrote: > I've been given conflicting device on which language to use. There > are people I would consider to be expert professionals who tell me > to use VHDL, and others who tell me Verilog. Here's an article on that: https://www.nandland.com/articles/vhdl-or-verilog-for-fpga-asic.htmlArticle: 160160
On 21/06/17 14:08, Rick C. Hodgin wrote: > I've been given conflicting device on which language to use. There > are people I would consider to be expert professionals who tell me > to use VHDL, and others who tell me Verilog. Most everybody tells > me that if I use VHDL there's less chance for error, but that it > does take more effort to learn. > > Any thoughts? > Have you considered other possibilities? VHDL and Verilog are the two main HDL languages, but they are far from the only choices. There are many others, most of which give different ways to express the logic that at least some people consider clearer, less error-prone, or more productive. Usually these other tools include different ways to test or simulate the logic, and generate VHDL and/or Verilog output for synthesis with FPGA tools. Note that it is quite a while since I have done any FPGA designs, so my comments here are based on things I did many years ago, or things I have read about and learned about but not used in practice. So if anyone else has direct experience here, their comments would be valuable. But certainly if I were to start working on a new FPGA project, I would look much wider than Verilog or VHDL before deciding on the tools for the job. An obvious step up from Verilog is SystemVerilog. It gives a bit more structure to interfaces, has a few more types, and has different "always" blocks that reduce the risk of accidentally generating the wrong type of logic. It also has many new non-synthesizable features for making better simulation testbenches. Handel-C is an HDL that is a superset of C. It adds features such as parallel and sequential blocks, channels for communication between parallel threads, and HDL concepts such as reset, clocks, etc. MyHDL is a popular Python-based HDL. Since it is Python, you have a lot of freedom and flexibility that you might not get in a lower level HDL. It also means that your main testbench code can also be written directly in Python. Personally, I used Confluence a long time ago. This was a functional programming language HDL. However, the tool was very much a one-man project, and when he decided to move on to other things, the project disappeared - there was never a serious community around it. But I found the language let me write much smaller and simpler code, with fewer problems and shorter test/debug cycles, compared to Verilog. A big question in this is what sort of designs do you want to make? One concept that I like is higher level generators. For example, consider making peripherals that are memory mapped on a bus. Your peripherals will have some registers that can be read or written from the bus, and logic to actually /do/ something with the register values (such as a timer, a UART interface, or whatever). The bus interface part has a similar structure - you have a list of registers, information about their sizes, their offsets from the base address, their read/write capabilities. You have an address decoder for the bus, and a bus slave interface that depends on the bus protocol. You can write such a bus interface in straight Verilog or VHDL. And once you have made an interface component for a UART, you can use it repeatedly for as many UARTs as you want. But when you want to make the interface for a timer peripheral, it is copy-and-paste and then you modify it for the new peripheral. And so on. VHDL generics might allow you a little more re-usability, but my understanding is that the implementation of them in existing tools is very limited. But in a higher level HDL, you can write a bus interface generator - a function or component that takes a list of registers and their details, and generates an instance of an interface. So once that generator is written, you can use it for all your different peripherals.Article: 160161
On Wednesday, July 13, 2011 at 7:27:03 AM UTC+6, aisitei wrote: > Hi. > I'm just beginner in making fpga > and i want to make MIPI CSI-2 to parallel converter in fpga. > > i think there are strange point. > in mipi spec, there are two mode, LP and HS mode, and these are very > different. > > how can i connect mipi p/n pins to fpga? Use this : https://github.com/daveshah1/CSI2RxArticle: 160162
On Thursday, June 22, 2017 at 5:13:02 AM UTC-4, David Brown wrote: > On 21/06/17 14:08, Rick C. Hodgin wrote: > > I've been given conflicting device on which language to use. There > > are people I would consider to be expert professionals who tell me > > to use VHDL, and others who tell me Verilog. Most everybody tells > > me that if I use VHDL there's less chance for error, but that it > > does take more effort to learn. > > > > Any thoughts? > > Have you considered other possibilities? VHDL and Verilog are the two > main HDL languages, but they are far from the only choices... Thank you for your guidance, David. Your input is appreciated. Thank you, Rick C. HodginArticle: 160163
On 06/22/2017 02:12 AM, David Brown wrote: > You can write such a bus interface in straight Verilog or VHDL. And > once you have made an interface component for a UART, you can use it > repeatedly for as many UARTs as you want. But when you want to make the > interface for a timer peripheral, it is copy-and-paste and then you > modify it for the new peripheral. And so on. VHDL generics might allow > you a little more re-usability, but my understanding is that the > implementation of them in existing tools is very limited. > > But in a higher level HDL, you can write a bus interface generator - a > function or component that takes a list of registers and their details, > and generates an instance of an interface. So once that generator is > written, you can use it for all your different peripherals. > That's actually one of the features going into VHDL-2017, is the concept of higher level interfaces. So you'll be able to bring in an AXI package, say that an entity has a AXI interface port, and control the bus logic with a couple functions from that package without having to cut and paste all that boilerplate. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 160164
On Thursday, June 22, 2017 at 5:13:02 AM UTC-4, David Brown wrote:
> Have you considered other possibilities? VHDL and Verilog are the two
> main HDL languages, but they are far from the only choices...
To provide a little more detail, I know I've told you before that
I am going to author the Logician tool, which will allow a Blender
nodes-like ability to manipulate objects graphically, and to move
them in 3D space using OpenGL.
-----
I am a very visual person, and I have a hard time reading, and
despite my profession, that actually includes software code as
well. I prefer to draw things on white boards, on paper, to
have symbols used instead of words for things, etc. Also,
you've commented before on my unusual spacing in source files,
but I do that because another part of my brain is responsible
for organizing things geometrically, which relieves pressure on
my reading centers, making it easier for me to read.
So, my goals are to learn VHDL or Verilog, and then author the
Logician tool, and then have it translate the visual definition
of that tool into the VHDL or Verilog syntax language for use in
traditional tools. I do not plan to remain in VHDL or Verilog
for very long.
And for my immediate need, I'm getting conflicting guidance from
the group I've recently become involved with, and I just wanted
some advice from the FPGA group here. For the time being, I'll
be using Arduino to get my product working while I continue to
devote time to learning my Altera or Lattice FPGA toolkits in
the evenings and weekends.
-----
To all: I could use some assistance in working with Altera's
Quartus on a Cyclone V GX Starter Kit, or Lattice's
Diamond on an ECP5.
Thank you,
Rick C. Hodgin
Article: 160165Rick C. Hodgin: > On Thursday, June 22, 2017 at 5:13:02 AM UTC-4, David Brown wrote: >> Have you considered other possibilities? VHDL and Verilog are the two >> main HDL languages, but they are far from the only choices... > > To provide a little more detail, I know I've told you before that > I am going to author the Logician tool, which will allow a Blender > nodes-like ability to manipulate objects graphically, and to move > them in 3D space using OpenGL. > > ----- > I am a very visual person, and I have a hard time reading, and > despite my profession, that actually includes software code as > well. I prefer to draw things on white boards, on paper, to > have symbols used instead of words for things, etc. Also, > you've commented before on my unusual spacing in source files, > but I do that because another part of my brain is responsible > for organizing things geometrically, which relieves pressure on > my reading centers, making it easier for me to read. > > So, my goals are to learn VHDL or Verilog, and then author the > Logician tool, and then have it translate the visual definition > of that tool into the VHDL or Verilog syntax language for use in > traditional tools. I do not plan to remain in VHDL or Verilog > for very long. > > And for my immediate need, I'm getting conflicting guidance from > the group I've recently become involved with, and I just wanted > some advice from the FPGA group here. For the time being, I'll > be using Arduino to get my product working while I continue to > devote time to learning my Altera or Lattice FPGA toolkits in > the evenings and weekends. > > ----- > To all: I could use some assistance in working with Altera's > Quartus on a Cyclone V GX Starter Kit, or Lattice's > Diamond on an ECP5. > > Thank you, > Rick C. Hodgin Visual or graphic entry design tools for HDLs are somewhat out of favour at the moment. (But not with me !) The only serious one I know (and use every day) is the Block Diagram Editor in Aldec-HDL. If you want a tool just to use you can buy that (Aldec-HDL Desktop edition) for about £1600. If you want to create your own tool you will need some helpers - it's more than a one man job. There is a tool in Vivado but it's not really the same kind of thing. I find the ability to describe a complex project with hierarchical block diagrams to be very useful. Since the VHDl (or Verilog) is generated from the diagrams you get customer friendly documentation that is actually up to date ! MKArticle: 160166
On Friday, June 23, 2017 at 4:04:57 AM UTC-4, Michael Kellett wrote:
> Rick C. Hodgin:
> > On Thursday, June 22, 2017 at 5:13:02 AM UTC-4, David Brown wrote:
> >> Have you considered other possibilities? VHDL and Verilog are the
> two
> >> main HDL languages, but they are far from the only choices...
> >=20
> > To provide a little more detail, I know I've told you before that
> > I am going to author the Logician tool, which will allow a Blender
> > nodes-like ability to manipulate objects graphically, and to move
> > them in 3D space using OpenGL.
> >=20
> > -----
> > I am a very visual person, and I have a hard time reading, and
> > despite my profession, that actually includes software code as
> > well. I prefer to draw things on white boards, on paper, to
> > have symbols used instead of words for things, etc. Also,
> > you've commented before on my unusual spacing in source files,
> > but I do that because another part of my brain is responsible
> > for organizing things geometrically, which relieves pressure on
> > my reading centers, making it easier for me to read.
> >=20
> > So, my goals are to learn VHDL or Verilog, and then author the
> > Logician tool, and then have it translate the visual definition
> > of that tool into the VHDL or Verilog syntax language for use in
> > traditional tools. I do not plan to remain in VHDL or Verilog
> > for very long.
> >=20
> > And for my immediate need, I'm getting conflicting guidance from
> > the group I've recently become involved with, and I just wanted
> > some advice from the FPGA group here. For the time being, I'll
> > be using Arduino to get my product working while I continue to
> > devote time to learning my Altera or Lattice FPGA toolkits in
> > the evenings and weekends.
> >=20
> > -----
> > To all: I could use some assistance in working with Altera's
> > Quartus on a Cyclone V GX Starter Kit, or Lattice's
> > Diamond on an ECP5.
> >=20
> > Thank you,
> > Rick C. Hodgin
>=20
> Visual or graphic entry design tools for HDLs are somewhat out of favour
> at the moment. (But not with me !) The only serious one I know (and use
> every day) is the Block Diagram Editor in Aldec-HDL. If you want a tool
> just to use you can buy that (Aldec-HDL Desktop edition) for about
> =C5=811600.
I'd be curious to see how it looks. I plan on mine being basically
this simple:
Note: I have not listened to the audio on this video, but
muted it and looked at the nodes illustration.
https://www.youtube.com/watch?v=3DHro1BIWFEDQ&t=3D1m38s
> If you want to create your own tool you will need some helpers -
> it's more than a one man job.
I'll be sure to ask for helpers on the project. :-)
> There is a tool in Vivado but it's not really the same kind of thing.
> I find the ability to describe a complex project with hierarchical block
> diagrams to be very useful. Since the VHDl (or Verilog) is generated
> from the diagrams you get customer friendly documentation that is
> actually up to date !
I know when I sit down to think things through, it goes so much more
easily for me to think in concepts than in mechanics. I think the
visual tool will allow me to both.
But, I have several steps ahead of Logician in line:
Visual FreePro, Jr.
RDC and CAlive (compiler framework and C-like compiler)
Visual FreePro (full version)
ES/2 operating system (an open source OS/2 clone)
Logician
My various hardware designs
My long-term vision for completing these things are through
2025 if I can find revenue to allow me to devote my day labor
hours to these projects, and some help. Otherwise, it will
be a remainder-of-my-life kind of thing (I'm 47 now).
Thank you,
Rick C. Hodgin
Article: 160167Hi there, I am looking for an expert on how to by-hand-configure MGTs individually of an single quad. I have an Artix 35T, the first MGT has to do aurora, the second and third one has to do JESD204b. I am offering a consulting fee for teaching me personally and/or working design of POR up to exchange of comma characters. Cheers, TobiasArticle: 160168
> I'll publish the article as soon as it is reviewed by my employer. >=20 > Kevin, if you have an Google account you can request access to the draft = and I'll grant it to you. Ilya, Thanks for the document. You inspired me to use non-project mode and now t= hat I have a script for one of my projects I can just keep reusing it. The= only thing I'd say about your document is that I think it had some Windows= -specific stuff which wasn't obvious to me at first. There is also a brief intro to non-project mode in the Vivado Quick Referen= ce: http://tinyurl.com/yb9d8y8dArticle: 160169
Hello, all, I have an old design implemented in the Xilinx 9572, and need to update it. Using ise 13.4, I created a new project, imported the files, and found it won't fit in the 9572XL, which was a big surprise. Although the 9572 was fairly full, the design easily fit there, and I just recompiled it for the 9572, and this version of ise easily fit it. Does anybody have any suggestions on settings to make it fit in the XL? The error messages suggest reducing the collapsing input limit or the product term limit. I did this in the Design goals and Strategies, but at the end of the fitter report it still shows the default values. Is there a trick to making it use the modified limits and other options? Not only does the 95144XL cost a bit more, but it is only available in the next size up package. Thanks very much for any help. JonArticle: 160170
Jon Elson wrote: > Hello, all, > > I have an old design implemented in the Xilinx 9572, and need to update > it. Using ise 13.4, I created a new project, imported the files, and found > it > won't fit in the 9572XL, which was a big surprise. Although the 9572 was > fairly full, the design easily fit there, and I just recompiled it for the > 9572, and this version of ise easily fit it. > Ah, I found that the REAL place you set the options is right clicking the fit button then properties. With a little adjustment of parameters, it did fit, but seems to use a little more resources than on the 9500. But, I have to add 2 signals to the state machine to control an external bi-directional level translator, so with it so close to the limit, I think it will be necessary to move up to the 95144XL part. JonArticle: 160171
Do you know something about free IP cores for this fpga? Xylon IPs are too expensive for me. Cheers, ucyArticle: 160172
On 07/13/2017 09:05 PM, Jon Elson wrote: > Jon Elson wrote: > >> Hello, all, >> >> I have an old design implemented in the Xilinx 9572, and need to update >> it. Using ise 13.4, I created a new project, imported the files, and found >> it >> won't fit in the 9572XL, which was a big surprise. Although the 9572 was >> fairly full, the design easily fit there, and I just recompiled it for the >> 9572, and this version of ise easily fit it. >> > Ah, I found that the REAL place you set the options is right clicking the > fit button then properties. With a little adjustment of parameters, it did > fit, but seems to use a little more resources than on the 9500. But, I have > to add 2 signals to the state machine to control an external bi-directional > level translator, so with it so close to the limit, I think it will be > necessary to move up to the 95144XL part. > > Jon > The one thing I'd mention is, have you tried comparing the portion-by-portion resource usage breakdowns between the 9572 and 9572XL builds? It may be there was one section of the design that the synthesizer got confused about in the XL and blew up. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.Article: 160173
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: 160174
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. -- Cecil - k5nwa
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
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