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
I would like to use an FPGA for a motor control application. I have worked with FPGAs before and am comfortable with what needs to be done inside the FPGA, where I need some advice is how to interface the FPGA with the outside world. At the end of the chain I need to generate an analog command voltage (multiple channels actually). My initial idea was to use a Cypress PSOC as the DAC and talk between the FPGA and PSOC using the I2C protocol. I've used I2C between multiple PSOCs and have had no problems, the question is how difficult it would be to implement an I2C master in the FPGA (I'm looking at using an Altera Cyclone II). Along those lines, I also would like to have communication between multiple FPGA based motor controllers. Again, I was thinking I2C. Does anyone see any major hangups or problems with this approach? Any simpler implementation I am overlooking? What is the most common form of digital communication used with an FPGA? How about interfacing to a DAC? Thanks JimArticle: 97851
Isaac, igelado@gmail.com wrote: > I made a hardware module which gets as input all the PCI interrupt > lines and merges them into a single one. The merge is done in the same > way the misc_logic module of the Xilinx base configuration, it means > all inputs are inverted except the SBR one. > > When using this hardware configuration the kernel is unable to boot. I > think due to the interrupt line is always asserted. Does anybody know > the correct way of merging the interrupt signals? I assume you just copied the fragment from the misc_logic core, that does the interrupt signal merging? Is the merged signal still connected to the same port on the interrupt controller? JohnArticle: 97852
Antti Lukats wrote: > "Ivan" <gmivan@terra.es> schrieb im Newsbeitrag > news:HA2Nf.665634$kp.4685064@telenews.teleline.es... > > compile the uclinux kernel as described here > > http://www.itee.uq.edu.au/~pml/uclinux_powerpc/ So you discovered our work on PPC Linux - it had to happen eventually I suppose! > I think the same system can run full linux as well, because > the ppc uclinux actually is using MMU already so it is > almost full linux, I was using ppc uclinux as next step > simply because of previous experience with Microblaze > uclinux. It is "full Linux". We are just building an auto-config'd PPC Linux kernel inside the uClinux / SnapGear Linux build system. It's completely MMU enabled, etc etc. Nothing "uC" or noMMU about it. JohnArticle: 97853
On a sunny day (28 Feb 2006 13:51:27 -0800) it happened "redstripe" <jim.bogdanowicz@gmail.com> wrote in <1141163487.818702.322540@z34g2000cwc.googlegroups.com>: >I would like to use an FPGA for a motor control application. I have >worked with FPGAs before and am comfortable with what needs to be done >inside the FPGA, where I need some advice is how to interface the FPGA >with the outside world. At the end of the chain I need to generate an >analog command voltage (multiple channels actually). My initial idea >was to use a Cypress PSOC as the DAC and talk between the FPGA and PSOC >using the I2C protocol. I've used I2C between multiple PSOCs and have >had no problems, the question is how difficult it would be to implement >an I2C master in the FPGA (I'm looking at using an Altera Cyclone II). >Along those lines, I also would like to have communication between >multiple FPGA based motor controllers. Again, I was thinking I2C. > >Does anyone see any major hangups or problems with this approach? Any >simpler implementation I am overlooking? What is the most common form >of digital communication used with an FPGA? How about interfacing to a >DAC? > >Thanks >Jim I dunno, but I have used simple PWM and low pass filtering te generate an analog voltage for about 500 outputs, depends on how fast the voltage needs to change.Article: 97854
For dual read ports and a single write port, this is easy. You just use two RAMs and always write to both of them together, but read from them separately, with each treated as a separate read port. For dual write ports, it gets a lot harder.Article: 97855
"Peter Alfke" <peter@xilinx.com> wrote in message news:1141144187.181979.144900@e56g2000cwe.googlegroups.com... > Frank, you posted this in the FPGA newsgroup. > In FPGAs, most RAM structures are naturally dual-ported, e.g. the > Virtex BlockRAMs. > You get two ports, whether you asked for it or not! > Peter Alfke, Xilinx Applications. > Yeah, the original codes are designed with Xilinx DPRAM with a functional testbenches, now I need to convert the codes into ASIC implementation. The tougher part of it is, I have little understanding of the functionality of the design.Article: 97856
<sharp@cadence.com> wrote in message news:1141166824.018412.3910@j33g2000cwa.googlegroups.com... > For dual read ports and a single write port, this is easy. You just > use two RAMs and always write to both of them together, but read from > them separately, with each treated as a separate read port. For dual > write ports, it gets a lot harder. > Yeah, there are RAMs in the ASIC library supporting dual read/single write. I need to make dual read/write out of it. How can I do it now? Thanks.Article: 97857
As someone else suggested, you could time-multiplex the two ports, which will take a double-speed clock and extra logic for the multiplexing. And this assumes that you are treating this as a synchronous RAM. And someone else suggested that you look at your application and see whether you really need a full dual-port RAM, or whether you are dealing with a special case where you can segregate it into independent parts. You could build the memory from multiple smaller RAMs and add decode logic to allow you to do two writes, as long as the writes were to separate RAMs. If they weren't, one of them would have to wait until the next cycle. This requires that the other logic trying to do the write be able to wait if the memory was "busy". Note that real dual-port memories are effectively implemented this way, except that the RAM granularity is a single word in the memory. The designers of those have the advantage that they are designing all the decode logic, down to the word level. You can reduce the chance of collisions in this scheme by choosing which address bits select a RAM and which ones select a word in the RAM, if you know something about the likely access patterns. For example, it may be more likely that two memory writes are going to the same half of the memory than that they are both going to even (or odd) addresses. If you can't multiplex, and can't deal with collisions, then you are out of luck. If you want to use predefined RAMs with their predefined single-port decoding logic, then you are stuck. Getting true dual-port requires specialized decode logic in the RAM.Article: 97858
In article <1141147160.445793.104550
@p10g2000cwp.googlegroups.com>, brimdavis@aol.com says...
> Jerry Coffin wrote:
> >
> > As such, insisting that something be 3E based, but then
> > complaining that only big/expensive ones have as many
> > I/Os as you want doesn't seem to make a lot of sense.
> >
> It makes perfect sense that someone looking to test the
> new Spartan-3E I/O's would want to use a S3E, not an S3
Yes, that would certainly be true.
I can't say a lot for certain yet, but I'm supposed to be
getting one of these sometime fairly soon, and I'm hoping
to use some differential I/O. OTOH, it sounds like you're
mostly interested in differential output, where I'll be
using mostly differential inputs. If it comes to that,
the 4 signals or so with (optional) nearby grounds will
(barely) handle what I need for differential inputs, so I
think it'll probably work for what I need in any case,
but my first attempt will probably be without adding
grounds.
Of course, it will probably also help that this will only
be at 400 MHz...
--
Later,
Jerry.
The universe is a figment of its own imagination.
Article: 97859
Kolja Sulimma <news@sulimma.de> writes:
> Make sure to translate the don't cares to your VHDL and to use a
> synthesis tool that makes use of the don't cares. AFAIK ISE just set's
> all specified don't cares to '0'.
It was convenient to translate it to VHDL concurrent assignments of the
form:
p126 <= '1' when (i_word and "010..11") = "010..10"
else '0';
ISE seems to understand this part just fine; I wasn't sure whether
a comparison with "X" in the literal would work:
p126 <= '1' when i_word = "X1X...10"
else '0';
Of course, the other option would be:
p126 <= i23 and ... and i1 and not i0;
> If there are any outputs that depend on less than 14 inputs push those
> into BlockRAMs.
There aren't; they all need more than 50.
Article: 97860I wrote: > But my own analysis > suggests that it should be possible to implement the PLA with no more > than 11 levels of logic worst case, seven levels for the product terms, > and 4 levels for the sums. Michael Hennebry wrote: > My analysis suggests 3+5=8 as the > minimum number of levels of 4-input luts: > 4*4*4=64> 25 and 4*4*4*4*4=1024> 512. > A product could require up to 8 luts, > a sum up to (2**9+1)/3=171 > for a total of 512*8 + 32*(2**9+1)/3=9568 luts. > What am I missing? I was tired and confused the count of levels with the number of LUTs needed for one term. The input terms need up to seven LUTs but only in three levels as you state. For the sum terms, none have more than 256 inputs, so four levels is OK. Thus my PLA shouldn't need more than seven levels of logic. I'm working on a new version of my Python PLA-to-VHDL converter that will explicitly instantiate LUT primitives. It treats the AND and OR arrays separately. For each array, it finds the most common four-input subexpression, generates a LUT for it, substitutes that LUT output back into the original equations, and iterates. I haven't quite got it working yet. EricArticle: 97861
redstripe wrote: > I would like to use an FPGA for a motor control application. I have > worked with FPGAs before and am comfortable with what needs to be done > inside the FPGA, where I need some advice is how to interface the FPGA > with the outside world. At the end of the chain I need to generate an > analog command voltage (multiple channels actually). My initial idea > was to use a Cypress PSOC as the DAC and talk between the FPGA and PSOC > using the I2C protocol. I've used I2C between multiple PSOCs and have > had no problems, the question is how difficult it would be to implement > an I2C master in the FPGA (I'm looking at using an Altera Cyclone II). > Along those lines, I also would like to have communication between > multiple FPGA based motor controllers. Again, I was thinking I2C. > > Does anyone see any major hangups or problems with this approach? Any > simpler implementation I am overlooking? What is the most common form > of digital communication used with an FPGA? How about interfacing to a > DAC? The simplest export scheme is SPI, which is also much faster than i2c. i2c also has poorer noise immunity, so that needs watching in a Motor Controller app. That said, if you can only get your DACs in i2c, then the decision is made for you. An i2c master will need a manager state engine, to handle ACK/NACK instances, and bus lockup recovery, as well as organise the address / data. -jgArticle: 97862
[ranton] Considering the vast improvements in DSP-type IP and chip resources, I'm baffled as to why multiply-accumulate (MAC) is not included in the average set of floating point operator cores and FPUs. It just seems fundamental to me. Using heavily pipelined atomic multipliers and adders makes for an awefully slow MAC. [rantoff] Those wishing to impelement such a thing should look up Yong Dou's work on the internet. Here's one link: ce.et.tudelft.nl/publicationfiles/973_567_f43-dou.pdfArticle: 97863
Greetings, We are doing a design that uses an Altera Cyclone II to drive three DDR2 memory chips. Looking at reference designs from Altera, TI and another company the terminations run the spectrum from series parallel (Altera), just series (TI) to no resistor termination (the other company). So my questions are to those designers who have DDR2 interface experience are: 1. What kind of terminations did you use? 2. Did you model the PWB and simulate for signal integrity? 3. If you did sim the PWB how close did the simulation results agree with the results from physical PWB? 4. What simulation tool did you use, was it lumped or distributed modeling? Regards JerryArticle: 97864
Eric Smith wrote: > I'm working on a new version of my Python PLA-to-VHDL converter that > will explicitly instantiate LUT primitives. It treats the AND and OR > arrays separately. For each array, it finds the most common four-input > subexpression, generates a LUT for it, substitutes that LUT output back > into the original equations, and iterates. I haven't quite got it > working yet. Sounds interesting. Can you keep notes on the FPGA tools handling of the various assistance levels, and report back when you have it working ? - and if you are doing AND and OR arrays separately, then the CPLD XC2 flow I suggested would make another good comparison. - ie compare your PLA optimizer with theirs ... -jgArticle: 97865
Hello everybody: I was given this board but I can not find the datasheet of it. It has a Virtex II device (XC2V1000FG256) on it. Next to Insight Xilinx logo there printed Virtex-II LC Board Revision 2 May/2001 JBE/JBE. Anybody has this datasheet and can drop me an email at kelvin_xq@yah(remove_this)oo.com? Thanks in advanceArticle: 97866
Sounds like a powerful FPGA argument: Ifyou really need a true dual-port memory (read and write from either or both ports simultaneously), you are out-of-luck in the ASIC world, but you can do this just fine in FPGAs. Nice to know we have such an edge... Peter Alfke, XilinxArticle: 97867
Matthias Alles wrote: > has anyone an idea how to isolate the problem? How about connecting one module at a time and synthesize it? That way, you will know which module causes the problem. HendraArticle: 97868
Jim Granville wrote: > The simplest export scheme is SPI, which is also much faster than > i2c. i2c also has poorer noise immunity, so that needs watching in a > Motor Controller app. That said, if you can only get your DACs in > i2c, then the decision is made for you. An i2c master will need a > manager state engine, to handle ACK/NACK instances, and bus lockup > recovery, as well as organise the address / data. -jg There are both I2C and SPI (master) cores on opencores. I've used both and they work for me. Regards, MarkArticle: 97869
"Frank @ CN" <Frank@Frank.com> skrev i meddelandet news:du1a67$9g1$1@reader01.singnet.com.sg... > Hi, there: > > In my application, a RAM needs to be written/read from two sets of > data/address ports > simultaneously. However, in the ASIC library I can only instantiate some > single port RAM > and RAM which can be written in one port and read from the other port. > > How shall I solve this problem? > > Thank you. > > You can instantiate FOUR rams and implement a valid bit for each location in a register. PortA can write to RAM0,RAM1 and read from RAM0 and RAM2 PortB can write to RAM2,RAM3 and read from RAM1 and RAM3 When PortA writes to address position 17, both RAM0[17] and RAM1[17] are updated and the VALID_BIT[17] is set to 0 indicating that RAM0,1 are valid instead of RAM2,3. When PortB reads address position 17, both RAM1 and RAM3 are read. A multiplexer on the output is controlled by the selected VALID_BIT, and since VALID_BIT[17] is zero, it will select the output of RAM1 over RAM3. Obviously this is going to use some gates,so it is not practical for large SRAMs. Running the RAM at 2 x frequency is going to cost a lot less. -- Best Regards, Ulf Samuelsson This is intended to be my personal opinion which may, or may bot be shared by my employer Atmel Nordic ABArticle: 97870
Thanks for all your responses. I didn't seem like Xilinx has support for checkpointing of the swift models. To get around this issue, I have been letting the simulation run well past where I think will be analyzing....So far, that works for me. NN Brian Drummond wrote: > On Thu, 23 Feb 2006 17:50:15 +0000 (UTC), Brian Drummond > <brian_drummond@btconnect.com> wrote: > > >On 22 Feb 2006 16:30:02 -0800, "Nju Njoroge" <njoroge@stanford.edu> > >wrote: > > > >>Hello, > >> > >>I have set-up checkpointing in ModelSim 6.0b (also using EDK 7.1 SP2). > >>ModelSim complains that "two foreign architectures are missing save and > >>restore callbacks" when I checkpoint. These "foreign architectures" > >>happen to be the PPC swift models. When I restore the checkpoints, the > >>waveforms are fully restored. However, I cannot continue the simulation > >>because it makes the following complaint: > >> > >># ** Fatal (SmartModel): > >># SWIFT protocol: > >># The first call to lsm_Model_DCEvaluate must occur at time 0. > >># Time: 424875000 ps > >>Instance:/system/ppc405_0/ppc405_0/ppc405_i/ippc405_swift/ppc405_swift_inst > >># ** Fatal: Foreign module requested halt. > >># Time: 424875 ns Iteration: 0 Foreign Process: > >>/system/ppc405_0/ppc405_0/ppc405_i/ippc405_swift/ppc405_swift_inst/SmartModel > >>File: Foreign > >># Fatal error at an unknown location > >># > >> > >>Anyone encountered this issue? > > > >Not quite; but I am having problems AT time 0ps; with the message > > > ># ** Fatal (SmartModel): > ># SWIFT protocol: > ># Call to lsm_Model_DCEvaluate must be preceded by a call > ># to lsm_Model_SetSimTimeUnit. > > > >May be related; I don't have any answers yet. (I have had other projects > >simulate correctly with SwiftModels; but this is my first of any > >complexity, as opposed to EDK projects with one toplevel ISE module) > > > > Mine appears to be related to starting ModelSim from within another tool > (HDL Designer). The SmartModels don't seem to play well with the other > stuff involved (cross-probing with the block diagrams). > > I don't know if this sheds any light on the checkpointing problem; > suspect it doesn't. > > - BrianArticle: 97871
"John Williams" <jwilliams@itee.uq.edu.au> schrieb im Newsbeitrag news:newscache$bv4fvi$2x6$1@lbox.itee.uq.edu.au... > Antti Lukats wrote: > >> "Ivan" <gmivan@terra.es> schrieb im Newsbeitrag >> news:HA2Nf.665634$kp.4685064@telenews.teleline.es... >> >> compile the uclinux kernel as described here >> >> http://www.itee.uq.edu.au/~pml/uclinux_powerpc/ > > So you discovered our work on PPC Linux - it had to happen eventually I > suppose! > >> I think the same system can run full linux as well, because >> the ppc uclinux actually is using MMU already so it is >> almost full linux, I was using ppc uclinux as next step >> simply because of previous experience with Microblaze >> uclinux. > > It is "full Linux". We are just building an auto-config'd PPC Linux > kernel inside the uClinux / SnapGear Linux build system. It's > completely MMU enabled, etc etc. Nothing "uC" or noMMU about it. > > John > Hi John, thanks for clarification, I did think that it is full linux as it was using the MMU 'in full' so I was wondering from what point of view it is 'uc'linux not full :) as I have said already, there isnt any magic required, no tricks, no issues, just build as described, (adjust RAM size if you have less memory) then start from RAM and you get linux prompt I am using small 'pre-boot' loader that sits in 16KB BRAM and loads images from sd-card, but loading with XMD works equally well nice, thanks ! AnttiArticle: 97872
So if you are back porting from FPGA to ASIC something stands out right away which makes this even more messy. Your logic & wiring paths will now gain significantly in performance but a comparable DPRAM is similar in performance between ASIC and FPGA for same feature and memory sizes since they are the same thing (almost). Perhaps there is an option to double up processing on the logic side rather than try to double up on SPRAM side. At this point I can only suggest before continuing with the ASIC, redo the FPGA design so that it also only uses 1 port atleast you don't burn masks, tie your hand behind your back on the cheap. Then it should be easier to convert, atleast you can prove the redesign before conversion. Your other option if you really really must use 2 concurrent writes with no other possibility is to go and get a DP WW RAM core from one of the ASIC IP houses, Mentor, Cadence, Synopsys and a couple of others come to mind, not sure who has which. I thought most of the asian foundries would include such blocks in their library, otherwise it seems you have a limited library. So what is the application, & size of DP WW RAM ? JohnArticle: 97873
The reason I ask for DP WW size is that for applications in say DSP and data buffering, the memory size might be large but there are possible options in architecture. In say a cpu datapath design with a N way ported register file the options may be far fewer but the size may be much smaller and ameniable to brute force as suggested by the 4 way Ulf design. That probably requires that a DP WW store stiil needs to be built but only for 1 bit direction flag and to the granularity of words or super words if I understand it right. JohnArticle: 97874
John Williams wrote: >> >> compile the uclinux kernel as described here >> >> http://www.itee.uq.edu.au/~pml/uclinux_powerpc/ > > So you discovered our work on PPC Linux - it had to happen eventually I > suppose! Hi John, I did not see the URL with details... but it is not a surprise for me that you are related with this work (PPC-uClinux). After your work in the uCLinux port to MicroBlaze, I think this port is full-functional too. I will follow the instructions... ;) Regards, Ivan P.S.: I am the same "Ivan" than writes in the uCLinux-MicroBlaze mailing list (salorankatu@yahoo.es), but here I use different e-mail address :)
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