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
In article <461257ca$0$6411$9b4e6d93@newsspool2.arcor-online.net>, "Andre Renee" <traubenuss@arcor.de> writes: |> |> Then I thought about Telnet but I am afraid I am not familiar enough with it |> to estimate if it allows the transfer of files. Is there any simple solution |> to transmit files from a PC to the FPGA board with a plain application |> protocoll layer? FTP or even TFTP. You can do it a lot more simply, but it sounds as if you aren't the sort of person who is happy designing a one-off protocol. WITH FTP, you need implement only one form of binary. Regards, Nick Maclaren.Article: 117526
"Andre Renee" <traubenuss@arcor.de> wrote in message
news:461257ca$0$6411$9b4e6d93@newsspool2.arcor-online.net...
> I implemented the TCP/IP stack fully in hardware in VHDL and it works.
Man!
> Is there any simple solution to transmit files from a PC to the FPGA board
> with a plain application protocoll layer?
Personally, I would look at GNU Netcat(http://netcat.sourceforge.net/) for
very simple file transfer over TCP/UDP. You might also try TFTP (yuk).
Good luck,
-Ben-
Article: 117527Andre Renee wrote: > Hi, > > I am currently working on a project where I have to transmit data from a PC > to an FPGA board via Ethernet. For that purpose I use the HTG-V4PCIe > evaluation board, which is a Xilinx Virtex-4 PCI Express Development Board > from HighTech Global (http://www.hitechglobal.com/boards/v4pcie.htm). It > features the Marvell Alaska 88E1111 Gigabit-Ethernet PHY which I use in > combination with the Virtex-4 built-in MAC interface. I implemented the > TCP/IP stack fully in hardware in VHDL and it works. Fine! :-) > > Now I have some serious problems with the data transmission and maybe > someone could point me to the right direction. > > For transmitting the data from the PC to the board (in the form of files) I > need some sort of application protocoll layer, I guess. First I thought > about HTTP which is in my opinion a bit overkill, because all I want to do > is transmit files FROM the PC TO the FPGA. I may run a HTTP server on the > FPGA's Microblaze but I have the impression that would not satisfy my need > of just transmitting data files. > Then I thought about Telnet but I am afraid I am not familiar enough with it > to estimate if it allows the transfer of files. Is there any simple solution > to transmit files from a PC to the FPGA board with a plain application > protocoll layer? > > Any help is highly appreciated. The simple way is TFTP. It uses UDP as the transport layer, so even TCP is not needed. However, there's practically no security, and the protocol is a simple send-and-wait-for- ack protocol. For local links, it's simple and works. TFTP was created to boot diskless workstations, and for similar tasks it's OK. For more general file transfer, FTP is probably the correct thing, although it's much more tedious to implement than TFTP. The primary reference for TFTP is <http://www.faqs.org/rfcs/rfc1350.html>. -- Tauno Voipio tauno voipio (at) iki fiArticle: 117528
On Apr 3, 8:59 am, Jan Panteltje <pNaonStpealm...@yahoo.com> wrote: > PS3 has only 1 power processor and _6_ SPE cores. > http://en.wikipedia.org/wiki/PlayStation_3#Central_processing_unit Nope, 1 central PPC core and 8 Synergistic Processor Unit: http://www.research.ibm.com/cell/heterogeneousCMP.htmlArticle: 117529
Hi Nick, thanks for your quick reply. The problem is: with my TCP/IP implementation I have only one port available. As far as I know with FTP I need at least two...!?Article: 117530
On Apr 3, 9:12 am, n...@cus.cam.ac.uk (Nick Maclaren) wrote: > In article <461257ca$0$6411$9b4e6...@newsspool2.arcor-online.net>,"Andre Renee" <trauben...@arcor.de> writes: > > |> > |> Then I thought about Telnet but I am afraid I am not familiar enough with it > |> to estimate if it allows the transfer of files. Is there any simple solution > |> to transmit files from a PC to the FPGA board with a plain application > |> protocoll layer? > > FTP or even TFTP. You can do it a lot more simply, but it sounds as > if you aren't the sort of person who is happy designing a one-off > protocol. WITH FTP, you need implement only one form of binary. > > Regards, > Nick Maclaren. If you have to write on the PC side as well, simple TCP socket communication should be simple. If not, just implement a simple TFTP server with the bare minimum in the FPGA, so you can connect from any computer with "tftp" command. Regards, ZoltanArticle: 117531
Hi,
Let me try this again.
The VHDL standards community has been considering whether
to enhance VHDL to add advanced testbench features.
If you are a VHDL user,
Do you want these features added to VHDL?
Would you rather adopt a verification language that
already supports these (SystemVerilog, SystemC, E, Vera).
I think VHDL needs these features to stay competitive.
The current plan in the VHDL working group is to make
these features similar to other verification languages
while at the same time keeping the nature of VHDL.
We need your to voice your support. You can post here,
send your reply to me (let me know if I can use either
your name and/or company name when I tally the results
for the Accellera VHDL TSC), or join the Accellera VHDL
TSC (which you can do as a non-Accellera member by
registering) and post your reply there.
More on the politics of the situation are below.
Thanks,
Jim Lewis
VHDL Evangelist
SynthWorks VHDL Training
P.S.
One of the simulator vendors has indicated that will
only implement new features if the user community
demands them. Business wise, this makes sense - you
don't build something unless someone will buy it.
If you fail to voice your support, they may be able to
successfully block these proposals from going forward.
If we let this opportunity to add these features to the
standard pass, I do not think we will have to opportunity
to add them later - hence you will be stuck with using
some other language for advanced verification features.
This work is work in progress and below is the current status.
Keep in mind too that your interest/support of this work will
help raise the focus and inspiration of those doing the work.
Classes / OO:
Classes are useful for creating verification data structures,
transaction communication, and grouping for transaction based
randomization (building relationships between separate data
items). Many of the data structures (such as scoreboards,
memories, and linked structures) can already be created, however,
classes give you the ability to hide all pointer manipulations.
For example, using a memory would require a declaration with
initialization of the memory data structure, then MemWrite and
MemRead would allow a user to store and retrieve items from the
data structure. Pointers and allocation of the sparse data
structure are handled by MemWrite and MemRead and the
user would not need to be aware of it.
Status:
Peter Ashenden submitted a class proposal last year and
provided updates to it this year at DVCon. Currently
he plans on finishing an updated draft soon.
Randomization:
Randomization is useful for designs that have numerous configurable
features. Testing features individually in an isolated manner is
typically straightforward. However, testing how these features
interact can be a large verification space – one that may not be able
to be simulated completely. It is also may be difficult to predict
all of the corner cases. Randomization has been used to sequence a
test in a non-deterministic way to get reasonably good coverage of
this verification space.
While I do not share the thought that randomization should be
adapted to work for all verification problems, I do believe it
to be a valuable technique for some problems.
I wrote a draft of the randomization proposal and it is ready
for review.
Functional Coverage:
Tool/structural coverage can tell you that you did a FIFO
read or that the the FIFO went empty, but it can't tell
you that you did a read while the FIFO was empty.
Functional coverage constructs allow you to track this.
Some functional coverage capability will come from assertions
(since PSL has been integrated into VHDL). Additional constructs
will be added to allow data binning (coverage groups) and
correlation between different coverage items (cross coverage).
I have started working on this - anyone else who is interested
is welcome to contribute as much as they would like.
With a focused effort, like the one to finish the Accellera 3.0
draft of the standard, I think we can be done with these by
September.
Although some have expressed doubt, it is clear that vendors
will do what their user community asks them to do - otherwise,
someone else will and, as a result, will earn your business.
Jim
Article: 117532Hi Jim, On 29 Mrz., 23:51, Jim Lewis <j...@synthworks.com> wrote: > Currently the Accellera VHDL TSC is working on enhancements > to add classes/OO, Randomization constructs, and Functional > Coverage with a goal of giving VHDL the same verification > capability as SystemVerilog or E. > > One of the VHDL simulation vendors has indicated that they > only want to implement new features if the user community > wants these features. I just started with VHDL two months ago and I have to say that I find it frustrating that I keep running into unimplemented parts of the VHDL standard. That's with the Xilinx toolchain and I read a lot of that already that I can confirm. A few days before I tried to model a ADC wrt. the timing constraints and had to notice that the Xilinx ISE Simulator (non ModelSim :() does not support the stable attribute. Okay, enough of the rant, what I wanted to say is that I'd expect the implementations to conform to the standard. > Classes / OO: > Peter Ashenden submitted a class proposal last year and > provided updates to it this year at DVCon. Currently > he plans on finishing an updated draft soon. I'd really like to see that proposal. Coming from software development it really seems logical to apply OO to HDLs. > Randomization: > I just submitted the first draft of the randomization proposal. Also very interesting, we will need pseudo random data for our project as well. Some kind of LFSR will be good enough but having it directly supported would be nice, also for synthesis. I can dream, right :) > You can post here, send your reply to me (let me know if I can use > either your name and/or company name when I tally the results > for the Accellera VHDL TSC), or join the Accellera VHDL TSC > (which you can do as a non-Accellera member by registering) > and post your reply there. While I am just starting with VHDL, I'd like to contribute. In fact, I became member of IEEE-SA just for that. I figured following that discussion would also be the best way to learn VHDL, just as my involvement with Debian GNU/Linux as a developer was a real boost for my Linux know how. However, I don't think my company is interested in spending money and developer time on it so I could only use my spare time for it. Greetings, TorstenArticle: 117533
Hi Jim, I just noticed that I did not really answer your questions, therefore I'll try again :-) On 29 Mrz., 23:51, Jim Lewis <j...@synthworks.com> wrote: > The questions come down to: > Do you want these features added to VHDL? > Do you want to VHDL to be capable of handling all of your > testbench needs? > [...] > > Classes / OO: > Peter Ashenden submitted a class proposal last year and > provided updates to it this year at DVCon. Currently > he plans on finishing an updated draft soon. Yes, classes/OO would be very welcome. > Randomization: > I just submitted the first draft of the randomization proposal. Same for randomization. > Functional Coverage: > I have started working on this - anyone else who is interested > is welcome to contribute as much as they would like. Everybody should want coverage tests as it is important for correctness. I am not sure though how this will require language changes? And of course I'd like to use only VHDL for our test benches. Tcl and VHDL kind of works but is not as portable and standardized. Greetings, Torsten PS: I am working for nAmbition GmbH but any opinions given above are my own. Feel free to use my name.Article: 117534
Well I have a strange problem. I have a VirtexIIPro30 on a Sundance target. I use XPS 8.2.02 to create a design with a 16KB of plb_bram_if_cntlr, and GPIO LED with bandwith 2. I add a Test_App Peripheral for testing leds but it seems like powerpc doesn't boot (work). I don't see the leds on and I have probed the design in a Microblaze on a Spartan. The test app is fine. PD: I have not JTAG for debugging. I have only an application to download "bitstream" and it is ok because I have download vhdl models on virtex. Does I have to init anything or use OCM?? ThanksArticle: 117535
[With apologies for re-ordering your questions:] > ... if you guys could give me some suggestions on a trivial example > for me to test and see that partial dynamic reconfig actually works > using the ICAP. If you're wondering whether it actually works, yes it does, and very nicely. > ... I would assume that the patial bitstreams would be generated > using the FPGA editor from Xilinx. The bitstreams would in fact be generated by bitgen, though you could use HDL source or EDIF netlists or FPGA Editor to generate the .ncd that bitgen would use. You can pass "-r <original.bit>" to bitgen to ask it to generate a bitstream that only includes frames that differ between your original bitstream and your new bitstream. That's how partial bitstreams are created. Because you're interested in active reconfiguration (i.e. reconfiguration of the FPGA while it's running), you also have to tell bitgen not to shut down the device, by passing "-g ActiveReconfig:Yes" to bitgen. Otherwise the very first thing the bitstream will do is stop the FPGA, and since you're reconfiguring the device from the inside, you'll have aborted the reconfiguration, with nothing to re-awaken the device. There are a few other considerations, such as not corrupting frames that contain LUT RAMs (including SRL16s) or BRAMs, but you probably don't need to worry about that quite yet. > Now assuming I want to have a set of bit streams loaded on to the > Internal memory buffer of the microblaze,How do I do that i.e how do > I store the bit streams on the microblaze(internal memory).I am using > an ML310 board. I'm not sure exactly what you're asking. When you speak of the "internal memory buffer of the microblaze", are you thinking of BRAM inside the FPGA, as opposed to external memory on the ML310 board? (And do keep in mind that the XC2VP30 on your ML310 only has about 306 KB of BRAM.) What exactly are you running? Is this uClinux on a MicroBlaze on the ML310? (I'm using regular Linux on PowerPC on the XUP V2Pro, so I can't directly provide you with an example.) And what are you trying to do with this? Or are you simply trying to verify to your own satisfaction that the concept does work? As for talking to the ICAP, you can use John's ICAP driver if you're running uClinux. Or you can use http://www.ccm.ece.vt.edu/~nsteiner/icap/ if you're running regular Linux (at least for kernel 2.4.x). Or you can always talk directly to the Xilinx xhwicap driver, instead of going through a Linux/uClinux driver. Documentation for the xhwicap driver is available with the EDK, and the source for John's driver or for my driver may help you better understand how to talk to the xhwicap driver. If you start making progress with this, then consider the following correction to the xhwicap driver: http://groups.google.bs/group/comp.arch.fpga/browse_thread/thread/02e00d4ec0ef783e This correction will spare you some grief if you're trying to write multiple frames without aligning them on boundaries. Probably something that you don't need to worry about yet though.Article: 117536
On a sunny day (3 Apr 2007 08:21:24 -0700) it happened "Patrick Dubois" <prdubois@gmail.com> wrote in <1175613684.443163.290410@d57g2000hsg.googlegroups.com>: >On Apr 3, 8:59 am, Jan Panteltje <pNaonStpealm...@yahoo.com> wrote: >> PS3 has only 1 power processor and _6_ SPE cores. >> http://en.wikipedia.org/wiki/PlayStation_3#Central_processing_unit > >Nope, 1 central PPC core and 8 Synergistic Processor Unit: >http://www.research.ibm.com/cell/heterogeneousCMP.html Nope, in the PS3 only 6 are available.Article: 117537
On Apr 3, 11:10 am, Jim Lewis <j...@synthworks.com> wrote: > Hi, > Let me try this again. > > The VHDL standards community has been considering whether > to enhance VHDL to add advanced testbench features. > > If you are a VHDL user, > Do you want these features added to VHDL? > Would you rather adopt a verification language that > already supports these (SystemVerilog, SystemC, E, Vera). > > I think VHDL needs these features to stay competitive. > > The current plan in the VHDL working group is to make > these features similar to other verification languages > while at the same time keeping the nature of VHDL. > > We need your to voice your support. You can post here, > send your reply to me (let me know if I can use either > your name and/or company name when I tally the results > for the Accellera VHDL TSC), or join the Accellera VHDL > TSC (which you can do as a non-Accellera member by > registering) and post your reply there. > > More on the politics of the situation are below. > > Thanks, > Jim Lewis > VHDL Evangelist > SynthWorks VHDL Training > > P.S. > One of the simulator vendors has indicated that will > only implement new features if the user community > demands them. Business wise, this makes sense - you > don't build something unless someone will buy it. > > If you fail to voice your support, they may be able to > successfully block these proposals from going forward. > > If we let this opportunity to add these features to the > standard pass, I do not think we will have to opportunity > to add them later - hence you will be stuck with using > some other language for advanced verification features. > > This work is work in progress and below is the current status. > Keep in mind too that your interest/support of this work will > help raise the focus and inspiration of those doing the work. > > Classes / OO: > Classes are useful for creating verification data structures, > transaction communication, and grouping for transaction based > randomization (building relationships between separate data > items). Many of the data structures (such as scoreboards, > memories, and linked structures) can already be created, however, > classes give you the ability to hide all pointer manipulations. > For example, using a memory would require a declaration with > initialization of the memory data structure, then MemWrite and > MemRead would allow a user to store and retrieve items from the > data structure. Pointers and allocation of the sparse data > structure are handled by MemWrite and MemRead and the > user would not need to be aware of it. > Status: > Peter Ashenden submitted a class proposal last year and > provided updates to it this year at DVCon. Currently > he plans on finishing an updated draft soon. > > Randomization: > Randomization is useful for designs that have numerous configurable > features. Testing features individually in an isolated manner is > typically straightforward. However, testing how these features > interact can be a large verification space - one that may not be able > to be simulated completely. It is also may be difficult to predict > all of the corner cases. Randomization has been used to sequence a > test in a non-deterministic way to get reasonably good coverage of > this verification space. > While I do not share the thought that randomization should be > adapted to work for all verification problems, I do believe it > to be a valuable technique for some problems. > > I wrote a draft of the randomization proposal and it is ready > for review. > > Functional Coverage: > Tool/structural coverage can tell you that you did a FIFO > read or that the the FIFO went empty, but it can't tell > you that you did a read while the FIFO was empty. > > Functional coverage constructs allow you to track this. > Some functional coverage capability will come from assertions > (since PSL has been integrated into VHDL). Additional constructs > will be added to allow data binning (coverage groups) and > correlation between different coverage items (cross coverage). > > I have started working on this - anyone else who is interested > is welcome to contribute as much as they would like. > > With a focused effort, like the one to finish the Accellera 3.0 > draft of the standard, I think we can be done with these by > September. > > Although some have expressed doubt, it is clear that vendors > will do what their user community asks them to do - otherwise, > someone else will and, as a result, will earn your business. > > Jim Yes! I whole-heartedly support expanding the "testbench" features of VHDL. The main problem with using separate languages to create the testbench are two-fold. 1) multi-language simulators are more expensive, and 2) there are always some gotcha's at the interface when it comes to connecting the testbench to the UUT, especially if you use other than SL or SLV port types for your UUT. That being said, I would caution against creating too much variance in VHDL between what can be done in a simulation only environment, vs a synthesis environment. OO principles come to mind. The eventual application of OO to synthesis should be carefully considered when developing the OO structure and syntax, even though it is now just for simulation. Also, there are plenty of areas in synthesizable vhdl that need work too, like user definable modes for record ports, expanded integer synthesis (boolean operator definition, expanded range), as well as fixed point representations along the lines of ada. AndyArticle: 117538
Andy, Thanks for your post. We are in the position where we need to hear all users speak up (privately to me is ok), even when they agree with what has already been stated. > Yes! I whole-heartedly support expanding the "testbench" features of > VHDL. The main problem with using separate languages to create the > testbench are two-fold. 1) multi-language simulators are more > expensive, and 2) there are always some gotcha's at the interface when > it comes to connecting the testbench to the UUT, especially if you use > other than SL or SLV port types for your UUT. > > That being said, I would caution against creating too much variance in > VHDL between what can be done in a simulation only environment, vs a > synthesis environment. OO principles come to mind. The eventual > application of OO to synthesis should be carefully considered when > developing the OO structure and syntax, even though it is now just for > simulation. > > Also, there are plenty of areas in synthesizable vhdl that need work > too, like user definable modes for record ports, expanded integer > synthesis (boolean operator definition, expanded range), as well as > fixed point representations along the lines of ada. Record ports is high on my list too. Have to finish the verification features first. The other items you mention also sound interesting. Cheers, JimArticle: 117539
Herbert Kleebauer wrote: >We use in a laboratory course still XILINX XC3000 FPGAs with >Viewlogic's Workview design entry (DOS version) and XILINX >XACT (also DOS). The problem is that we have to replace the >old PC's and that Viewlogic only supports a few graphics modes >and it is unlikely that it will run on new PC's. The last >version of XILINX ISE software which supports XC3000 FPGA's >isn't an alternative (and I'm not sure whether it will >run on W2k/XP) because the system must be extremely easy to >use so the students are able to design and implement a simple >CPU in about 10 hours (including the time to learn how to use >the schematic entry and simulation tool). > >Some questions: > >1. I have tried to find an actual FPGA with a package which can > be soldered with a non professional equipment, something like > a PLCC84 where you can get cheap sockets which can be used on > You can use Xilinx Spartan chips such as XCS10-xPC84 (x is the speed grade). I don't remember how big the array goes in the PC84 package. With a little more soldering skill, there are flat pack Spartan chips, such as 144-pin. You need to use Xilinx's ise 5.2 or earlier software to generate configs for these older chips. Despite Xilinx pulling all references to them off their web site, the 5 V Spartans are still available. They are a little harder to get in small quantity, but if you need 50 or something, it would be no problem. > self made PCBs and if possible with a VCC of 5 V to easy interface > with external TTL logic. XILINX and ACTEL only offers packages with > > JonArticle: 117540
Herbert Kleebauer wrote: >The problem is not the money, but the time of the students. >The system must be very easy to use so the students can built >the simple CPU at gate level in 10 hours including the time to >learn the tools. > This is a fantasy! You could probably design a 2-bit adder at the gate level in 10 hours, starting from not knowing the package. There is no way a student could design a CPU at the gate level, unless it was maybe a Turing machine (one-bit CPU), in 10 hours. Even if they were fluent in VHDL, every toolkit has its own dialect of what is accepted and what is not. Then, you have to learn the simulator, how to write test benches, debug the board, the FPGA soldering, testing the FPGA config ON the target board..... I run Xilinx ise 5.1 and 5.2 on Windows 2000. I'm still working in the 5 V world for a little while longer. JonArticle: 117541
Herbert Kleebauer wrote: >msg wrote: > > >>Herbert Kleebauer wrote: >> >> > > > >>>2. Was somebody able to run Viewlogic (DOS version) in a virtual >>> PC emulation. The problem is, the virtual PC must provide >>> the proper graphics mode, mouse type and support a physical >>> dongle on the virtual parallel port. >>> >>> > > > >>Also, it would be an interesting experiment to try running >>the software on a VMWare MSDOS VM (a no-cost experiment); please >>report the results! >> >> > > > I run Xilinx ise 5.2 on Windows 2000 under VMware, using Linux as the host OS. Win 2K is MUCH more reliable under VMware than on real hardware. It stays up for months at a time. I program EPROMS and download to CPLDs through the JTAG on the parallel Cable III pod. JonArticle: 117542
cs_posting@hotmail.com wrote: >But the fact of the matter is that there is hidden technology at all >levels of the system. As has been pointed out, the tools don't >implement the actual gates you've drawn, they implement a logical >equivelent. And there's also sorts of hidden semi-proprietary stuff >on the FPGA die. You may find this easier to ignore with an older >part, but it's still true. Unless you go back to very raw TTL type >chips (or maybe even earlier), what your students will be designing >with is a black box abstraction that _does not really match_ its >logical symbol representation except in explicit ways the data sheet >says it does. > > > The abstraction of the logic doesn't matter in the sense of a truth table (as long as it is complete). The result will match the truth table for sure. But, the actual logic pathways will not bear any resemblence to the schematics, and so the timing will be radically different than what is drawn. Of course, with good logic design, it will still meet the design spec, but with crummy design planning, it sure won't. JonArticle: 117543
Markus Knauss wrote: > Hi all, > > at the moment, we are using AT17LV010 configuration devices for a > spartan 2S100. > I have to look for a different solution which is not so expensive. > > The Xilinx XC17V01 is OTP and more expensive than the AT17LV010. > > Does someone know a different prom (OTP, EEPROM, Flash)? SST makes a series of VERY cheap serial flash memories. I figured out how to create the command bit stream that it needs to command a read starting from addr zero function, using just 2 SSI CMOS chips in SSOP packages, so the interface is under $1, and the SST chip is well under $2 in small quantities. I had to make my own programmer, and a little C program to read the .MCS file and program the device. I haven't actually produced a product using this setup yet, but I did build a prototype board for Spartan 2E and verify that it could do the FPGA configure. I did this for the 2S50E part, but SST has up to 4 mbit chips, I think, that should handle the 2S100. JonArticle: 117544
Hi everyone, I'm working on a Board for Bus Interfacing and some Audio Processing, which will use Spartan 3E 1200 and the Microblaze. Now I'm not sure what kind of memory I should use. Size ist not too important for me. 8Mbytes would be ok, but more is always better. But the speed should be high enough to get the Microblaze run at a decent speed and to allow permanent storing auf 4 stereo audio streams. Most important is, that the layout and memory interface should run stable and from the beginning. There's not much time for error investigations and redesigns. Spartan 3E Starter Kit uses a 16bit Wide DDR SDRAM Memory. But I read here and in some other boards, that people have much trouble with this one. Is this because Spartan 3E and the given IP Cores have always Trouble with DDR, or because of the missing clock feedback path on the board? Another option would be normal SDRAM Memory. I think this should give less trouble. But here I'm wondering that Xilinx doesn't mention the Spartan 3E in the Device Family Support List of the OPB SDRAM Controller and the MultiChannel OPB SDRAM Controller. Only Spartan 3 and 3A are supported according to the Links on this page: http://www.xilinx.com/ise/embedded/edk_ip.htm In fact the Spartan 3E is only listed in the support list for the OPB DDR SDRAM Controller. Are there mistakes in this list, or is spartan 3e really not supported by most memory controllers? Greetings MatthiasArticle: 117545
On Apr 3, 2:25 pm, Jim Lewis <j...@synthworks.com> wrote: > Andy, > Thanks for your post. We are in the position where we need to > hear all users speak up (privately to me is ok), even when they > agree with what has already been stated. > > > > > Yes! I whole-heartedly support expanding the "testbench" features of > > VHDL. The main problem with using separate languages to create the > > testbench are two-fold. 1) multi-language simulators are more > > expensive, and 2) there are always some gotcha's at the interface when > > it comes to connecting the testbench to the UUT, especially if you use > > other than SL or SLV port types for your UUT. > > > That being said, I would caution against creating too much variance in > > VHDL between what can be done in a simulation only environment, vs a > > synthesis environment. OO principles come to mind. The eventual > > application of OO to synthesis should be carefully considered when > > developing the OO structure and syntax, even though it is now just for > > simulation. > > > Also, there are plenty of areas in synthesizable vhdl that need work > > too, like user definable modes for record ports, expanded integer > > synthesis (boolean operator definition, expanded range), as well as > > fixed point representations along the lines of ada. > > Record ports is high on my list too. Have to finish the verification > features first. The other items you mention also sound interesting. > > Cheers, > Jim These new features are greatly needed and appreciated. -- AmalArticle: 117546
Consider the NOR Flash attached to the Spartan-3E starter kit's FPGA. "Matthias Einwag" <matthias.einwag@web.de> wrote in message news:euufee$non$1@inn-newsserver.rz.tu-ilmenau.de... > Hi everyone, > > I'm working on a Board for Bus Interfacing and some Audio Processing, > which will use Spartan 3E 1200 and the Microblaze. > Now I'm not sure what kind of memory I should use. Size ist not too > important for me. 8Mbytes would be ok, but more is always better. But the > speed should be high enough to get the Microblaze run at a decent speed > and to allow permanent storing auf 4 stereo audio streams. > Most important is, that the layout and memory interface should run stable > and from the beginning. There's not much time for error investigations and > redesigns. > > Spartan 3E Starter Kit uses a 16bit Wide DDR SDRAM Memory. But I read here > and in some other boards, that people have much trouble with this one. Is > this because Spartan 3E and the given IP Cores have always Trouble with > DDR, or because of the missing clock feedback path on the board? > > Another option would be normal SDRAM Memory. I think this should give less > trouble. But here I'm wondering that Xilinx doesn't mention the Spartan 3E > in the Device Family Support List of the OPB SDRAM Controller and the > MultiChannel OPB SDRAM Controller. Only Spartan 3 and 3A are supported > according to the Links on this page: > http://www.xilinx.com/ise/embedded/edk_ip.htm > In fact the Spartan 3E is only listed in the support list for the OPB DDR > SDRAM Controller. Are there mistakes in this list, or is spartan 3e really > not supported by most memory controllers? > > Greetings > MatthiasArticle: 117547
Jon Elson wrote: > > > Herbert Kleebauer wrote: > >> The problem is not the money, but the time of the students. >> The system must be very easy to use so the students can built >> the simple CPU at gate level in 10 hours including the time to learn >> the tools. >> > This is a fantasy! You could probably design a 2-bit adder at the gate > level in 10 hours, starting from not knowing the package. There is no > way a student could design a CPU at the gate level, unless it was maybe > a Turing machine (one-bit CPU), in 10 hours. Even if they were fluent in > VHDL, every toolkit has its own dialect of what is accepted and what is > not. Then, you have to learn the simulator, how to write test benches, > debug the board, the FPGA soldering, testing the FPGA config ON the > target board..... I think Herbert was using the time, to illustrate the need for schematic flow, and built might not have meant physically assemble a PCB, but probably includes bitstream and prom generate. You are both right - Herbert has a very short time or this section of the course, and yes, full VHDL Xilinx tool flows, will have too long a learning curve. His ideal is to continue to run the old Viewlogic system, and I think some posts offered some hope. Failing that, I've suggested a Boolean Eqn entry scheme, that does have a shorter learning curve, and is quick to run - and that is close enough to the gate-level to see the AND.OR.Registers I have one ToolChain here, on a Flash drive, in under 10MB. -jgArticle: 117548
Hello again,
First, as a side note, Xilinx has so far gone out of their way to get
me the ability to file Webcases, and I'm grateful to everyone who
helped in that process, most notably, because he's where the ball
started rolling, Austin. (And, I will file Webcases, but I've been
sick since last Wednesday)
However, I've run into a rather odd situation which I haven't yet been
able to figure out, and I'm not sure that this rises to the level of
actually filing a web case at this point. Hopefully someone with more
experience with the Xilinx tools will be able to point me in the right
direction to figuring the situation out.
First, the background:
I'm creating an RS232 module which has send & receive. I calculate
the basic ratio of clock frequency for the RS232 like this:
constant clock_ratio : integer := clock_rate / bps;
Where 'clock_rate' is 50,000,000 and 'bps' is 115200.
I have a generic library which will generate a clock of a particular
frequency, given a parameter 'n', which is the ratio of the FPGA clock
to the desired clock -- in other words, 'clock_ratio.
signal tx_clk : std_logic;
signal rx_clk : std_logic;
After the requisite parameter checking (i.e., ensure that 'bps > 0'), I
generate the transmit and receive clock signals like this
rs232_tx_clk : entity clkdiv
generic map (n => clock_ratio)
port map(clkin => clk,
reset => '0',
clkout => tx_clk);
rs232_rx_clk : entity clkdiv
generic map (n => clock_ratio * 16)
port map(clkin => clk,
reset => '0',
clkout => rx_clk);
end generate;
When running, 'bitgen' produces the following warning:
WARNING:PhysDesignRules:372 - Gated clock. Clock net
rs232_port/tx_clk is sourced by a combinatorial pin. This is
not good design practice. Use the CE pin to control the loading
of data into the flip-flop.
'rs232_port/tx_clk' refers to the signal shown above, and it's the
clock signal for the RS232 TX block.
There is no warning for the 'rx_clk' signal, and if I change the 'n'
value of the instantiation of 'clkdiv' from 'clock_ratio' to
'clock_ratio * 16', as present for the 'rx_clk' generation, the
warning disappears.
My questions are these:
-- Why does the warning appear? As far as I can tell, there should
be no combinatorial circuit -- but I'm a newbie, so I'm probably
wrong. (If the clkdiv source is required, I can provide it)
-- Can anyone give me a clue why multiplying the ratio by 16 causes
the warning to go away?
-- What can I do, besides multiplying by 16, to get the error to go
away? (There is probably not enough information posted in this
message to answer this question)
-- Is there any way, short of looking at the ISE's RTL schematic, to
see what the combinatorial circuit comprises (it's not obvious
from the sources, as far as I can tell)?
Thanks for the help,
thutt
Article: 117549Problem solved. I contacted Xilinx, and they responded promptly that I should upgrade my ModelSim to 6.2c that contains the new libraries.
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