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
Another advantage to FPGAs is that the work can be migrated to an ASIC, yeilding further speed gains. For serious projects, that can be a real advantage. JJ wrote: > Nico Coesel wrote: >> helmut.leonhardt@gmail.com wrote: >> >>> Everything what can parallelize is possibly running faster in Hardware >>> than in Software. >> Still, the amount of processing power a modern PC processor can >> deliver is enormous. It is problably more cost effective to optimize >> an algorithm to run parallel on 10 PC's than to develop a specific >> FPGA solution. If space is a constraint, the answer is in using blade >> servers. >> > > This is often true even for obvious applications of FPGA, PC can still > be better. > > The analysis needs to account for factors such as floating point use, > high locality referencing or lots of computing on tiny data sets and > use of standard 32, 64 bit operands favors PCs On the other hand bit > mangling, very high rates of memory shuffling, use of unusual bit wise > or odd size mathematical operators and strategic use of buffer memories > are a win for FPGAs. > > I suspect that as Flash drives replace hard drives at the 30GByte level > the case for hardware taking control of data management in Flash only > increases since a hardware FPGA design wouldn't usually include disk > systems and can then push the PC host further away. > > Some problems can be factored both ways to get similar results in which > case PCs still have the familiarity edge. Still a PC based solution > that is just recompiled to hardware will perform far less well since > it has already been factored to favor the PC. > > For a hardware solution, the software version can be viewed as the > simulation of same hardware and most simulations usually run many > orders slower than real hardware. > > This is why the best hardware solution is unlikeley to ever be achieved > by software folks who have little experience in hardware who would > force the FPGA to emulate the PC strengths. > > John Jakson > transputer guy >Article: 111526
Frank van Eijkelenburg wrote: > Jaime Andr=E9s Aranguren Cardona wrote: > > Hi, > > > > I installed XPS - EDK 8.1i in my WinXP machine. When I try to call XPS > > the DPS window appears, and dissapears within a few seconds and nothing > > else happens. Reviewing the C:\EDK folder, a file bash.exe.stackdump > > appears, which contents are: > > > > Exception: STATUS_ACCESS_VIOLATION at eip=3D00000000 > > eax=3D00000000 ebx=3D0247ED28 ecx=3D0247EB64 edx=3D7C91EB94 esi=3D0247E= D2C > > edi=3D00000000 > > ebp=3D0247ED30 esp=3D0247ED08 program=3DC:\EDK\cygwin\bin\bash.exe, pid= 1680, > > thread main > > cs=3D001B ds=3D0023 es=3D0023 fs=3D003B gs=3D0000 ss=3D0023 > > Stack trace: > > Frame Function Args > > End of stack trace > > > > How could I fix this? > > > > Regards. > > > > Did you also installed ISE 8.1?! ISE and EDK must have the same version n= umbers. > > Frank Hi Frank, Yes, they are the same version. Seems like something else messed the system up. Not even deinstalling and reisntalling fixed the issue. Only re-formatting the HDD and starting it all from scratch could fix it. Now it works flawless, as it used to. Kindest regards, JaaCArticle: 111527
"Mike Treseler" <mike_treseler@comcast.net> wrote in message
news:4quvu0Foq72hU1@individual.net...
> KJ wrote:
>
>> But you didn't answer the question....reworded to 'What is the name of
>> that
>> standard IP'? lpm_fifo is the only one that I can think of that fits
>> your
>> functional description. Writing the function yourself (while you may
>> want
>> to do it anyway) does not qualify it as a 'standard'. You write good
>> code
>> Mike, but not everything you write is ready to be called a standard ;)
>
> Ready or not,
> I'll call it sync_fifo.
> See it here:
> http://home.comcast.net/~mike_treseler/
I've got the definite impression that we are not on the same page when we
talk about what it means for something to be 'standardized'. The usage I'm
talking about is that something 'standardized' if it is interchangable with
something else that accomplishes that same function but not necessarily in
the same way. Although the fifo functionality is pretty low level, since
you suggested it I'll use it for the example....it will also be a good
indicator of exactly what I mean about the lack of standardization even on
something that is easy to describe.
Copied below (without permission of the authors but only done for
demonstration purposes) are the entity definitions for 'lpm_fifo' (an EIA
standard) and 'sync_fifo' (Mike Tressler standard). Keeping mind what it is
that a fifo is supposed to do (the function) and the intended USER of the
fifo who has to deal with the interface to that function (i.e. signals and
generics on the entity) let's peruse these two.
Both have generics for specifying width of the fifo...but can't agree on the
name of that generic parameter.
Both have generics for specifying the depth of the fifo....but again can't
agree on the name of that generic parameter. Both are bad from the
standpoint of the user since Mike makes you specify depth as an address
length (which is really log2(depth)) and lpm_fifo makes you use two
parameters (the depth and log2(depth)). Each has their own unique way of
not really telling you that their parameters really are simply log2(depth).
Lpm_fifo allows you an option (Lpm_Showahead) for having the output show up
as soon as it is available or only after in response to the read command.
sync_fifo has no similar option. Having used fifos for a number of years I
can say that both forms are generally useful depending on the application
and performance requirements so in that regard sync_fifo is less useful than
lpm_fifo.
Lpm_fifo has some mystery parameters (lpm_type and lpm_hint) that are
intended to be used to pass information further down the tool chain. From
the standpoint of a user of the fifo, they just clutter up the interface and
are no value. sync_fifo has nothing comparable so in that regard it is
better tham lpm_fifo. LPM intended those to be used to pass info on to the
fitter in some way but those strings are all going to be 'vendor specific'
so no kudos there.
Users of a fifo need to reset it, write to it and read from it. Again here
there is no naming consistency on any of the signals with the exception of
the 'full' and 'empty' status outputs. sync_fifo also has some two forms of
reset (rst and init) that apparently Mike has found to be useful that the
rest of the industry has not seen to be of enough value to include. Maybe
sync_fifo is more useful because of this...or maybe it was a band-aid for a
particular nitch problem but in most cases I would likely end up tying them
to the same signal or tying one of them to '0'. lpm_fifo also has two forms
of reset (async and sync); I won't rant on the dubious value of async resets
maybe some find value to it.
Although 'full' and 'empty' outputs are usually all that most users of a
fifo will need, there are more than a few occasions where more status is
needed. 'sync_fifo' does not provide anything, 'lpm_fifo' goes to the other
extreme and provides a raw dump of the count. What is generally more useful
would be to have a number of flag outputs where the depth where the flag
gets triggered can be specified by a generic value (like half full, three
quarters full, .98% full, etc.) Give both a failing mark on this for not
giving much thought to how fifos really get used.
Users of fifos tend to think of 'writing' and 'reading' the fifo, not
'pushing' and 'popping' it as sync_fifo does. In fact 'push' and 'pop' give
the implication of a stack (which is a "last in first out" memory) not a
fifo (which is "first in, first out") which would make one question whether
you're even using the right function so demerits to sync_fifo on that one.
So now that the long winded critique of two definitions of a fifo has been
completed, so what? Why does any of this matter? Mike would probably agree
that his 'sync_fifo' could very well have been implemented with the exact
same set of parameter and signal names as lpm_fifo but he chose not to. So
what is the impact of that decision? Well, if you want to switch from
lpm_fifo over to Mike's sync_fifo because maybe it is so much better you've
got a bunch of editing to do (every usage of lpm_fifo)...and yet sync_fifo
implements the EXACT SAME FUNCTION. Even worse, maybe you'd just like to
evaluate that supposed performance improvement.
You're not getting anything more, and maybe you're simply trying to figure
out if you get better performance using Mike's implementation but you've got
a bit of effort in front of you to do that evaluation. Why? Because the
interface to these two things that implement the EXACT SAME FUNCTION are
completely different. Which is the situation that we're in today. Some
FPGA vendors support the one sorry standard that exists (LPM) but are not
doing much to improve it and move up the ladder to more higher level
functions while one large FPGA vendor (namely 'X') does not directly support
it that one standard...but they do provide their own unique way to implement
the EXACT SAME FUNCTION.
Peter Alfke goes off on his rant about his X's hard coded fifo runs at 550
MHZ but doesn't seem to grasp the fact that he is talking about performance
and that that hard coded fifo is implementing the EXACT SAME FUNCTION. I
find it hard to believe that the Xilnx tool set could not, once it
encountered the entity called 'lpm_fifo' that it could plop in that hard
coded block. Maybe there are some usage restrictions that would prevent
that hard coded block from always being instantiated but hey, isn't that
what synthesis is supposed to figure out? How to best implement the
specified function? Perhaps Peter can explain to everyone how the interface
to that Xilinx hard coded fifo differs in some fundamental manner that the
interface to that EXACT SAME FUNCTION could not be the same.
Last, I would like to thank Mike for making available his code on his web
site. His example designs are a definite 'good' thing. My comparisons of
Mike's fifo implementation to LPM fifo is not meant to imply that his is any
way worse just that it goes to show you that even with something simple,
agreement on the interface to the EXACT SAME FUNCTION differs for no
rational reason. Mike being able to reuse 'sync_fifo' wherever he needs
fifo functionality though is no different than any other FPGA vendor pushing
their 'standard'.
Look at the IC industry and how they can standardize on things and fairly
ask yourself why IP can't follow that model. Hint: The answer is not "Well
IP is not the same as ICs".....if you analyze it rationally I think you'll
see that the answer is more along the lines of "Well dang, it really could
be standardized and still come out with new stuff as well as improve on old
stuff".
KJ
-------------
entity LPM_FIFO
generic (
LPM_WIDTH : natural; -- MUST be greater than 0
LPM_WIDTHU : natural := 1; -- MUST be greater than 0
LPM_NUMWORDS : natural; -- MUST be greater than 0
LPM_SHOWAHEAD : string := "OFF";
LPM_TYPE : string := L_FIFO;
LPM_HINT : string := "UNUSED");
port (
DATA : in std_logic_vector(LPM_WIDTH-1 downto 0);
CLOCK : in std_logic;
WRREQ : in std_logic;
RDREQ : in std_logic;
ACLR : in std_logic := '0';
SCLR : in std_logic := '0';
Q : out std_logic_vector(LPM_WIDTH-1 downto 0);
USEDW : out std_logic_vector(LPM_WIDTHU-1 downto 0);
FULL : out std_logic;
EMPTY : out std_logic);
end LPM_FIFO;
entity sync_fifo is
generic (dat_length : natural := 16;
add_length : natural := 8 -- 7 for 127x16 8 for 255x16
);
port (clk : in std_ulogic;
rst : in std_ulogic; -- powerup init of pointers, flags
init : in std_ulogic; -- synch init of pointers, flags
-- (but not data)
push : in std_ulogic; -- data_i latched on edge after push
-- ok to push and pop at same time
pop : in std_ulogic; -- hold one tick, read data_q while low
data_i : in std_logic_vector(dat_length-1 downto 0);
data_q : out std_logic_vector(dat_length-1 downto 0); -- readback
full : out std_ulogic;
empty : out std_ulogic);
end sync_fifo;
Article: 111528rickman wrote: >>>Three dual 4 input muxes (analog switch based), a 4 bit counter, a dual >>>tri-state buffer, a dual NAND gate and a dual FF. Together with two 8 >>>bit SPI port relay drivers, they all fit in a 10 x 20 mm area. >> >>Up to here, I count only 33 macrocells, probably less. > > > This logic is only 15 or so MC. The part that controls the relays is a > bit more complex. I don't recall the exact MC count, but it was in the > low 50's for the whole shooting match, but that was not a formal, > complete analysis and would likely grow a bit. Then we have a > requirement for 40% spare capacity so that we can accommodate later > revisions and updates. That puts the design clearly in the 128 MC > part. > > > >> The >> >>>smallest CPLD I can easily use is a 128 macrocell part in a 100 pin >>>TQFP at 16 mm sq package and still requires the two relay drivers plus >>>a JTAG header. >> >>Why not use a 64MC device in CS package? > > > Actually, it has occured to me that I could do a combined approach > using a 32 or 64 MC CPLD to replace the discrete logic only and not the > relay drivers. An MCU could do the job of sorting out the SPI data and > provide "intelligence" for driving the relays. > > The MCU would have to be very low power, but that might be doable with > adequate power management. If the relay logic is that complex, why not use a uC and SPI relay drivers ? Look at the Silabs C8051F41x/F53x family. When I asked them about the SPI port waking up the on chip OSC, they said "Oh yes, the osc starts in spec almost instantly" (couple of cycles), and they have some clk ratio requirement anyway, so the upshot was, this chip could sit in deep sleep, and wakeup on SPI ready to service the first byte, then go back to deep sleep again : ie behave rather like Logic or a low power CPLD. -jgArticle: 111529
axalay wrote: > :) are you serious or it is joke? (it about distanse 70 and 71 mm) > No, it is serious ;) My PCB layout program will easily tell me the exact length of the traces, so I just fired it up and found out what the length was. I could have given the length to 3 decimal places, if desired ;)Article: 111530
Jhlw wrote: > See whole thread at: > http://groups.google.ca/group/comp.arch.fpga/browse_thread/thread/322e88de0fbb80e8/65ecc09c50ed8d9b?lnk=raot&hl=en#65ecc09c50ed8d9b > > I have been getting exactly the same output continually > from my project when I load it into my development board > (ML403), in spite of making changes that should cause > different output. When I did "Project -> Clean All Generated > Files" in EDK, I finally managed to get some changes to > appear. I have not used EDK 8.2 yet, but version 7.1 did not recognize changes to your custom cores automatically. Apparently that has not changed. There is a flag you can set to cause the cores to be rebuilt automatically every time. The very strange thing, is that EDK creates conventional make files, so it would be easy for it to detect changes in source files and rebuild when changes are detected. And in my case, that is what I have done. I take the EDK generated make files, edit them to add the appropriate lines to recognize changes in the source files, and then build projects from the command line with "make". > ... > It does seem to be my experience as a user with a couple of > months of experience that project files need to be cleaned in ISE, > too ... Unlike EDK, ISE has always correctly detected changes for me. I don't "clean" the files there, and use the GUI to rebuild. It now seems good enough for everyday use.Article: 111531
ALuPin@web.de wrote: >> or use something like >> >> ff_resetn:process(boot_clk) >> begin >> if (boot_clk'event and boot_clk='1') then >> if (reset_cnt/="111") then >> reset_cnt<=reset_cnt + 1; >> end if; >> reset_n<=(reset_cnt(2) AND reset_cnt(1) AND reset_cnt(0)); >> end if; >> end process; >> >> ff_reset:process(boot_clk) >> begin >> if (boot_clk'event and boot_clk='1') then >> reset<=not reset_n; >> end if; >> end process; > > How do you know which value "reset_cnt" will start with after > configuration ? > Rgds > André > you just write signal reset_cnt : std_logic_vector(2 downto 0) := (others=>'0'); so that when the FPGA is configured it always starts at 0Article: 111532
Roberto wrote: > I am trying to use Xilinx chipscope, but it is not working properly > (probably mishandling by the user...). Perhaps somebody can give me > some light... > > I used core inserter, and I have a ICON and a ILA core. > I want to monitor a SPI bus in a 2VP2 device, that has 12 RAM blocks > available. > I defined a 1 trigger port with width 1, set with the sclk (that > should be around 10MHz). > And I have a 40 data width bus where I try to see many data signals. > > I can go to the point where I generate the programming file (bit file). > Startup clock is set to JTAGclk, keep hierarchy is set to YES. I also > generate (just in case) the mcs file and load my 18V04 EEPROM. I > recicle power and then I click in the Analyze Design Using Chipscope. > After opening the JTAG Chain (XILINX Parallel IV cable), it says that > it found 1 core unit in the JTAG device Chain. But if I press the > "trigger now" button, it does not give me the status of the lines. It > enters a mode where it says"siting for core to be armed." and stays > there forever. Am I setting the trigger in a wrong way? > > We are talking about versions 7.1 os ISE and chipscope pro. > > I would appreciate any input! > just press the immediate sample/trigger button if you do not want to trigger for an event but just see the 'current' signal values ... OR setup the right triggers like Markus Meng saidArticle: 111533
lancepickens@gmail.com wrote: > Hi, > Coming from a scientific computing standpoint (with no hardware > experience). > I was wondering if you can improve any dedicated tasks by designing a > special > purpose chips ala FPGA to run your code? Does anyone have any > experience > with this? > <http://www.nallatech.com/?node_id=1.2.1&id=8> <http://www.sgi.com/products/rasc/> <http://www.cray.com/products/xd1/index.html> ...Article: 111534
Jim Granville wrote: > rickman wrote: > >>>Three dual 4 input muxes (analog switch based), a 4 bit counter, a dual > >>>tri-state buffer, a dual NAND gate and a dual FF. Together with two 8 > >>>bit SPI port relay drivers, they all fit in a 10 x 20 mm area. > >> > >>Up to here, I count only 33 macrocells, probably less. > > > > > > This logic is only 15 or so MC. The part that controls the relays is a > > bit more complex. I don't recall the exact MC count, but it was in the > > low 50's for the whole shooting match, but that was not a formal, > > complete analysis and would likely grow a bit. Then we have a > > requirement for 40% spare capacity so that we can accommodate later > > revisions and updates. That puts the design clearly in the 128 MC > > part. > > > > > > > >> The > >> > >>>smallest CPLD I can easily use is a 128 macrocell part in a 100 pin > >>>TQFP at 16 mm sq package and still requires the two relay drivers plus > >>>a JTAG header. > >> > >>Why not use a 64MC device in CS package? > > > > > > Actually, it has occured to me that I could do a combined approach > > using a 32 or 64 MC CPLD to replace the discrete logic only and not the > > relay drivers. An MCU could do the job of sorting out the SPI data and > > provide "intelligence" for driving the relays. > > > > The MCU would have to be very low power, but that might be doable with > > adequate power management. > > If the relay logic is that complex, why not use a uC and SPI relay drivers ? > > Look at the Silabs C8051F41x/F53x family. > When I asked them about the SPI port waking up the on chip OSC, they > said "Oh yes, the osc starts in spec almost instantly" (couple of > cycles), and they have some clk ratio requirement anyway, so the upshot > was, this chip could sit in deep sleep, and wakeup on SPI ready to > service the first byte, then go back to deep sleep again : ie behave > rather like Logic or a low power CPLD. The original idea was the CPLD was needed and could provide the logic for the relay control too. It was only in the last couple of weeks that I realized that I couldn't get the chip on the board with the size of the relays that were selected. Then I realized that there was no real need for the "complex" control logic since that is only an artifact of the SPI bus protocol which I didn't think was cast in concrete. It's not, but because we are a sub working with a prime, we don't do squat without asking "mother may I". So we can treat the relay driver as a simple SPI relay driver and put the "intelligence" in existing processors on other boards. I think a Monahan should have enough horsepower to handle a relay drive when nothing else is going on. Or we can add an MCU and offload this burden from the slow 400 MHz processor to a 4 MHz MCU. My real concern is that the RF section can grow and squeeze the controller space even more. My point was that not so much because it is needed, but as a compromise I could use a small MCU and a small CPLD with the small relay driver chips. This is only a bit larger than the "dumb" approach. But it will require a lot more development work (remember this is a very inefficient company) and I will have a very hard time getting the support I need to fully test the board. The really sad part is that this is costing 10 to 100 times what it would cost in commercial work and it is being paid for by the Government.Article: 111535
There are plenty of scientific apps out there that are being sped up by FPGAs. I, for instance am just finishing up a 2D 32-2048 point floating point FFT engine in Virtex4 that can compute a 2D 2Kx2K FFT on complex data in under 13 msec including raster order input and output for an imaging application. It resides in a single Virtex4 SX55 with external QDR memory.Article: 111536
Hello. Got this board without any intention to use Nios, but just to use EP2S60 chip. Drawed very simple schematics, loaded it via EPCS config port (using Active Serial Programming method), powered it, and all LEDs are blinking, with about 2Hz frequency, except of those LEDs which was used in project. However, when one of LEDs must be turned on regarding my goal, it blinking modulated by about 2Hz. What is this? Probably some problem signalization, but where should I start?Article: 111537
Well, KJ, first of all, tone down, and dont second-guess how much I can grasp. "Peter Alfke goes off on his rant about his X's hard coded fifo runs at 550 MHZ but doesn't seem to grasp the fact that he is talking about performance and that that hard coded fifo is implementing the EXACT SAME FUNCTION." I have designed FIFOs over a longer time period than anybody else in the world, for I created the world's first IC FIFO design in 1970, the Fairchild 3341. So much for credentials... When we put a HARD FIFO into the Virtex-4 and Virtex-5 devices, we realized that it had to be fully functional, fast and small, for every BlockRAM is "burdened" with it. And once the transistors are implemented on the chip, there is nothing that can be changed or taken away, and any additional circuitry in the fabric would reduce performance significantly. (There was, unfortunately, a subtle error in the Virtex-4 implementation that forced us to come up with a work-araound. We did not repeat that mistake inVirtex-5). We had talked to many customers and listened to their ideas. That's why there are not only programmable "ALMOST" full or empty flag, there is also the "First-word-fall-though option", (Lpm_Showahead), and a synchronous option that avoids the one-clock ambiguity at the trailing edge of FULL or EMPTY (inherently unavoidable in an asynchronous FIFO, but avoidable in a synchronous one). We designed the FIFO to be fast and small, with a comprehensive and intuitive user interface. If somebody wants to have a different interface, thousands of gates and LUTs are available to implement that. Did we design the LUTs to a specific standard? Do SRL16 shift register abide by an industy-wide standard? Are clock-multiplexers standardized? How's about DCMs and PLLs, and IDELAY and ODELAY fine-tuning circuits, and even multiplier/accumulators. Of course not, none do! Inside the chip we optimize the circuitry, and we are running way ahead of standardization. But, thanks to programmable logic, you can add soft standardization layers to your heart's content. Nothing stops smart IP of implementing any conceivable standard, but unfortunately usually at a cost and performance sacrifice. If someone knows a smarter way to design FPGAs, we really are listening. Honest ! Our customers want performance at the lowest cost, plus ease-of-design. But everybody has his own ideas about relative priorities. Peter Alfke, from home ================== On Nov 4, 11:38 am, "KJ" <kkjenni...@sbcglobal.net> wrote: > "Mike Treseler" <mike_trese...@comcast.net> wrote in messagenews:4quvu0Foq72hU1@individual.net... > > > > > KJ wrote: > > >> But you didn't answer the question....reworded to 'What is the name of > >> that > >> standard IP'? lpm_fifo is the only one that I can think of that fits > >> your > >> functional description. Writing the function yourself (while you may > >> want > >> to do it anyway) does not qualify it as a 'standard'. You write good > >> code > >> Mike, but not everything you write is ready to be called a standard ;) > > > Ready or not, > > I'll call it sync_fifo. > > See it here: > >http://home.comcast.net/~mike_treseler/I've got the definite impression that we are not on the same page when we > talk about what it means for something to be 'standardized'. The usage I'm > talking about is that something 'standardized' if it is interchangable with > something else that accomplishes that same function but not necessarily in > the same way. Although the fifo functionality is pretty low level, since > you suggested it I'll use it for the example....it will also be a good > indicator of exactly what I mean about the lack of standardization even on > something that is easy to describe. > > Copied below (without permission of the authors but only done for > demonstration purposes) are the entity definitions for 'lpm_fifo' (an EIA > standard) and 'sync_fifo' (Mike Tressler standard). Keeping mind what it is > that a fifo is supposed to do (the function) and the intended USER of the > fifo who has to deal with the interface to that function (i.e. signals and > generics on the entity) let's peruse these two. > > Both have generics for specifying width of the fifo...but can't agree on the > name of that generic parameter. > > Both have generics for specifying the depth of the fifo....but again can't > agree on the name of that generic parameter. Both are bad from the > standpoint of the user since Mike makes you specify depth as an address > length (which is really log2(depth)) and lpm_fifo makes you use two > parameters (the depth and log2(depth)). Each has their own unique way of > not really telling you that their parameters really are simply log2(depth). > > Lpm_fifo allows you an option (Lpm_Showahead) for having the output show up > as soon as it is available or only after in response to the read command. > sync_fifo has no similar option. Having used fifos for a number of years I > can say that both forms are generally useful depending on the application > and performance requirements so in that regard sync_fifo is less useful than > lpm_fifo. > > Lpm_fifo has some mystery parameters (lpm_type and lpm_hint) that are > intended to be used to pass information further down the tool chain. From > the standpoint of a user of the fifo, they just clutter up the interface and > are no value. sync_fifo has nothing comparable so in that regard it is > better tham lpm_fifo. LPM intended those to be used to pass info on to the > fitter in some way but those strings are all going to be 'vendor specific' > so no kudos there. > > Users of a fifo need to reset it, write to it and read from it. Again here > there is no naming consistency on any of the signals with the exception of > the 'full' and 'empty' status outputs. sync_fifo also has some two forms of > reset (rst and init) that apparently Mike has found to be useful that the > rest of the industry has not seen to be of enough value to include. Maybe > sync_fifo is more useful because of this...or maybe it was a band-aid for a > particular nitch problem but in most cases I would likely end up tying them > to the same signal or tying one of them to '0'. lpm_fifo also has two forms > of reset (async and sync); I won't rant on the dubious value of async resets > maybe some find value to it. > > Although 'full' and 'empty' outputs are usually all that most users of a > fifo will need, there are more than a few occasions where more status is > needed. 'sync_fifo' does not provide anything, 'lpm_fifo' goes to the other > extreme and provides a raw dump of the count. What is generally more useful > would be to have a number of flag outputs where the depth where the flag > gets triggered can be specified by a generic value (like half full, three > quarters full, .98% full, etc.) Give both a failing mark on this for not > giving much thought to how fifos really get used. > > Users of fifos tend to think of 'writing' and 'reading' the fifo, not > 'pushing' and 'popping' it as sync_fifo does. In fact 'push' and 'pop' give > the implication of a stack (which is a "last in first out" memory) not a > fifo (which is "first in, first out") which would make one question whether > you're even using the right function so demerits to sync_fifo on that one. > > So now that the long winded critique of two definitions of a fifo has been > completed, so what? Why does any of this matter? Mike would probably agree > that his 'sync_fifo' could very well have been implemented with the exact > same set of parameter and signal names as lpm_fifo but he chose not to. So > what is the impact of that decision? Well, if you want to switch from > lpm_fifo over to Mike's sync_fifo because maybe it is so much better you've > got a bunch of editing to do (every usage of lpm_fifo)...and yet sync_fifo > implements the EXACT SAME FUNCTION. Even worse, maybe you'd just like to > evaluate that supposed performance improvement. > > You're not getting anything more, and maybe you're simply trying to figure > out if you get better performance using Mike's implementation but you've got > a bit of effort in front of you to do that evaluation. Why? Because the > interface to these two things that implement the EXACT SAME FUNCTION are > completely different. Which is the situation that we're in today. Some > FPGA vendors support the one sorry standard that exists (LPM) but are not > doing much to improve it and move up the ladder to more higher level > functions while one large FPGA vendor (namely 'X') does not directly support > it that one standard...but they do provide their own unique way to implement > the EXACT SAME FUNCTION. > > Peter Alfke goes off on his rant about his X's hard coded fifo runs at 550 > MHZ but doesn't seem to grasp the fact that he is talking about performance > and that that hard coded fifo is implementing the EXACT SAME FUNCTION. I > find it hard to believe that the Xilnx tool set could not, once it > encountered the entity called 'lpm_fifo' that it could plop in that hard > coded block. Maybe there are some usage restrictions that would prevent > that hard coded block from always being instantiated but hey, isn't that > what synthesis is supposed to figure out? How to best implement the > specified function? Perhaps Peter can explain to everyone how the interface > to that Xilinx hard coded fifo differs in some fundamental manner that the > interface to that EXACT SAME FUNCTION could not be the same. > > Last, I would like to thank Mike for making available his code on his web > site. His example designs are a definite 'good' thing. My comparisons of > Mike's fifo implementation to LPM fifo is not meant to imply that his is any > way worse just that it goes to show you that even with something simple, > agreement on the interface to the EXACT SAME FUNCTION differs for no > rational reason. Mike being able to reuse 'sync_fifo' wherever he needs > fifo functionality though is no different than any other FPGA vendor pushing > their 'standard'. > > Look at the IC industry and how they can standardize on things and fairly > ask yourself why IP can't follow that model. Hint: The answer is not "Well > IP is not the same as ICs".....if you analyze it rationally I think you'll > see that the answer is more along the lines of "Well dang, it really could > be standardized and still come out with new stuff as well as improve on old > stuff". > > KJ > ------------- > entity LPM_FIFO > generic ( > LPM_WIDTH : natural; -- MUST be greater than 0 > LPM_WIDTHU : natural := 1; -- MUST be greater than 0 > LPM_NUMWORDS : natural; -- MUST be greater than 0 > LPM_SHOWAHEAD : string := "OFF"; > LPM_TYPE : string := L_FIFO; > LPM_HINT : string := "UNUSED"); > port ( > DATA : in std_logic_vector(LPM_WIDTH-1 downto 0); > CLOCK : in std_logic; > WRREQ : in std_logic; > RDREQ : in std_logic; > ACLR : in std_logic := '0'; > SCLR : in std_logic := '0'; > Q : out std_logic_vector(LPM_WIDTH-1 downto 0); > USEDW : out std_logic_vector(LPM_WIDTHU-1 downto 0); > FULL : out std_logic; > EMPTY : out std_logic); > end LPM_FIFO; > > entity sync_fifo is > generic (dat_length : natural := 16; > add_length : natural := 8 -- 7 for 127x16 8 for 255x16 > ); > > port (clk : in std_ulogic; > rst : in std_ulogic; -- powerup init of pointers, flags > init : in std_ulogic; -- synch init of pointers, flags > -- (but not data) > push : in std_ulogic; -- data_i latched on edge after push > -- ok to push and pop at same time > pop : in std_ulogic; -- hold one tick, read data_q while low > data_i : in std_logic_vector(dat_length-1 downto 0); > data_q : out std_logic_vector(dat_length-1 downto 0); -- readback > full : out std_ulogic; > empty : out std_ulogic); > > end sync_fifo;Article: 111538
John Adair wrote: > One thing to check is that Impact is not open when using Chipscope. I > have seen cases of Impact affecting chipscope operation. > > John Adair > Enterpoint Ltd. > > kollarameshk@gmail.com wrote: >> Hi, >> I need help for solving the following problem.I am trying to >> connect to ML461 JTAG port from PC parallel port by using XILINX >> parallel cable through chipscope.But it couldn't connect properly.It >> gives the following error. >> >> ERROR: Socket Open Failed. localhost/127.0.0.1:50001 >> localhost >> java.net.ConnectException: Connection refused: connect >> ERROR: Failed to open Xilinx Parallel Cable. See message(s) above. >> >> And the same cable setup works properly with the another same board. >> >> I really appreciate your help. >> >> Thanks, >> -Ramesh > yes i had the same problems ... and yes [Markus Meng] the parallel pod is still supported (i still use it) ... maybe something to do with the IO settings of the parallel port (ECP/EPP...) i had to change this one in the beginning ...Article: 111539
Hi everybody, I have implemented a SDRAM Controller in Spartan 3s400.I already have another working core inside the same FPGA. when i try to implement my design with this, my device is not detected atall. In am in a very high pressure to complete this task. Can anybody help me please. Thanks, Amir.Article: 111540
Amirtham schrieb: > I have implemented a SDRAM Controller in Spartan 3s400.I already have > another working core inside the same FPGA. when i try to implement my > design with this, my device is not detected atall. Simulate you design - including SDF backannotation. Break your design into smaller components, Test these components. Feed interesting signals to output pins / LEDs. Generate Signals, that allow you decide, if a part is working or not. RalfArticle: 111541
Yeah, the core is not getting a clock signal. You stated that you connected SCLK to the trigger port of ChipScope. Is that really what you meant? If so, you never stated what the CLK port of chipScope is connected to, if anything.Article: 111542
I have implemented (-1,+1) boxed-constraint algorithm into FPGA desgin.
The algorithm is to solve the equation Rh+n=b in telecommunication
application. For my project case, all the elements of size NxN Matrix
R in the region [-1,1], and n is the Gauss noise. h is a size
Nx1vector . For example:
R =
1.0000 0.5000 0.5000 0.5000
0.5000 1.0000 0 0
0.5000 0 1.0000 1.0000
0.5000 0 1.0000 1.0000
b =
-1.2672
-0.5291
2.1703
1.2486
R1=round(2*R); b1=round(2*b);
It is easily seen that all elements can be presented by 4 bit. But for
the transmission to FPGA board, I extend sign bit to 8 bit . Then I
write Matrix R1 and vector b1 into FPGA board.
In Matlab simulation, I used constraint H=2^0 as the biggest step
size .Then is d=2^-1, d=2^-2....to approach the expected h value. So my
question is: Shall I use H=00000001 to presnted 1? Some said I used 4
bit to present input data. I should use 2^4 to present H. I don't agree
with it. And now I am a little confused about it. Does anybody can help
me figure me out? I have tried my best to explain it clearly. Thank
you very much.
Zhi
Article: 111543"Nico Coesel" <nico@puntnl.niks> wrote > helmut.leonhardt@gmail.com wrote: > >>Everything what can parallelize is possibly running faster in Hardware >>than in Software. > > Still, the amount of processing power a modern PC processor can > deliver is enormous. It is problably more cost effective to optimize > an algorithm to run parallel on 10 PC's than to develop a specific > FPGA solution. If space is a constraint, the answer is in using blade > servers. Well this power is precisely the problem of grid systems. I mean the real power in Watts. The modern PC have also problem with very very slow communication between them, and the current processors have also some issues with the very slow memory access. The good news is that it's even getting worse with the FBDIMM ;-) We are not doing scientific but financial computing so it's closely related. Though it's not always obvious to have an idea of what speed gain can be achieveable on FPGA systems, we have already got performance ratios of x50 to x140 on things like Monte-Carlo simulation for instance. MarcArticle: 111544
Hi all again, I have a fairly straight forward systolic array design which uses the fixed_point type. It simulates fine for the behavioral simulation. It synthesizes fine (there are a few warnings, but they appear to be OK)... but when I try to do a post-synthesis simulation in ModelSim, I get: ** Error: C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(237): Prefix of a slice must be a 1 dimensional array. ** Error: C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(237): Prefix of a slice must be a 1 dimensional array. ** Error: C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(237): Unknown identifier 'std_logic_vector2'. ** Error: C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(238): Prefix of a slice must be a 1 dimensional array. ** Error: C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(238): Prefix of a slice must be a 1 dimensional array. ** Error: C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(238): Unknown identifier 'std_logic_vector2'. ** Error: C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(239): Prefix of a slice must be a 1 dimensional array. ** Error: C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(239): Prefix of a slice must be a 1 dimensional array. ** Error: C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(239): Prefix of a slice must be a 1 dimensional array. ** Error: C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(239): Unknown identifier 'std_logic_vector3'. ** Error: C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(241): VHDL Compiler exiting Do I need to include some library that I'm not? What might be the issue? Thanks in advance, SergeyArticle: 111545
Forgot to include the actual lines that its erroring on:
inmatA : in STD_LOGIC_VECTOR2 ( 3 downto 0 , 16 downto 0 );
inmatB : in STD_LOGIC_VECTOR2 ( 3 downto 0 , 16 downto 0 );
outmat : out STD_LOGIC_VECTOR3 ( 3 downto 0 , 3 downto 0 , 16
downto 0 )
(I see that they're declared as multi-dimensional and probably aren't
supposed to be... but why is Xilinx translating them that way, and what
can I do about it?)
-- Sergey
sergey wrote:
> Hi all again,
>
> I have a fairly straight forward systolic array design which uses the
> fixed_point type. It simulates fine for the behavioral simulation. It
> synthesizes fine (there are a few warnings, but they appear to be
> OK)... but when I try to do a post-synthesis simulation in ModelSim, I
> get:
>
> ** Error:
> C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(237):
> Prefix of a slice must be a 1 dimensional array.
> ** Error:
> C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(237):
> Prefix of a slice must be a 1 dimensional array.
> ** Error:
> C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(237):
> Unknown identifier 'std_logic_vector2'.
> ** Error:
> C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(238):
> Prefix of a slice must be a 1 dimensional array.
> ** Error:
> C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(238):
> Prefix of a slice must be a 1 dimensional array.
> ** Error:
> C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(238):
> Unknown identifier 'std_logic_vector2'.
> ** Error:
> C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(239):
> Prefix of a slice must be a 1 dimensional array.
> ** Error:
> C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(239):
> Prefix of a slice must be a 1 dimensional array.
> ** Error:
> C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(239):
> Prefix of a slice must be a 1 dimensional array.
> ** Error:
> C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(239):
> Unknown identifier 'std_logic_vector3'.
> ** Error:
> C:/thesis/SDRE/VHDL/FINAL/mult/netgen/synthesis/mult_arr_synthesis.vhd(241):
> VHDL Compiler exiting
>
> Do I need to include some library that I'm not? What might be the
> issue?
>
> Thanks in advance,
>
> Sergey
Article: 111546"Peter Alfke" <alfke@sbcglobal.net> wrote in message news:1162698535.527609.266650@f16g2000cwb.googlegroups.com... > Well, KJ, first of all, tone down, and dont second-guess how much I can > grasp. > "Peter Alfke goes off on his rant about his X's hard coded fifo runs at > 550 > MHZ but doesn't seem to grasp the fact that he is talking about > performance > and that that hard coded fifo is implementing the EXACT SAME FUNCTION." I call them as I see them. You were the one who several times went on with the sales pitch on the 550 MHz fifo when we were talking about interface standardization, not performance. > I have designed FIFOs over a longer time period than anybody else in > the world, for I created the world's first IC FIFO design in 1970, the > Fairchild 3341. So much for credentials... Good, now let's move on. > > When we put a HARD FIFO into the Virtex-4 and Virtex-5 devices, we > realized that it had to be fully functional, fast and small, for every > BlockRAM is "burdened" with it. And once the transistors are > implemented on the chip, there is nothing that can be changed or taken > away, and any additional circuitry in the fabric would reduce > performance significantly. (There was, unfortunately, a subtle error in > the Virtex-4 implementation that forced us to come up with a > work-araound. We did not repeat that mistake inVirtex-5). Even now, instead of actually responding to anything that I had posted you are rambling on about things that Xilinx has done inside the various X products. It reads again like a sales pitch, give it a rest....the relevance of what you have to say to my post is completely missing.....maybe you intended this for some other post, who can tell? > We had talked to many customers and listened to their ideas. That's why > there are not only programmable "ALMOST" full or empty flag, there is I'm thinking that the programmable flags idea came not so much from listening to customers but from the discrete fifos that existed long before in the industry that also had 'programmable' flags. A bit of digging would've led you to that what most customers really needed was not programmability of the flag levels but being able to specify as a generic parameters the fifo fill level and how many flags were needed. The discrete IC fifo guys couldn't really do this so they had to make it programmable, but in the soft IP world of CPLD/FPGAs you could....but instead chose to copy industry parts. Maybe that's a good decision, maybe not but I'll bet not having run-time programmability is acceptable in most situations. For the others, this would be a different function (different entity). > We designed the FIFO to be fast and small, with a comprehensive and > intuitive user interface. Fifo interfaces are all pretty intuitive, so why does X not support the lpm_fifo interface? Is it not intuitive? > Are clock-multiplexers > standardized? How's about DCMs and PLLs, and IDELAY and ODELAY > fine-tuning circuits, and even multiplier/accumulators. Of course not, > none do! Why not? As a user I want to multiply and divide clock frequency, skew them if necessary and possibly mux them together. Sounds like something that can be standardized to me. Toss in standardization of the various memory controllers as well while you're at it since the memory devices are standardized. Remember what standardization means....interchangable with somebody else equivalent function. > Inside the chip we optimize the circuitry, and we are running way ahead > of standardization. That's your opinion (about being so far ahead). Does that statement also imply that Xilinx is just so far ahead that they can't bother with component standardization? That's another reading I could take away from that statement and seems to be what you're suggesting as well. > But, thanks to programmable logic, you can add soft standardization > layers to your heart's content. Nothing stops smart IP of implementing > any conceivable standard, but unfortunately usually at a cost and > performance sacrifice. Maybe. Are you suggesting that the lpm_fifo function wouldn't run at your horn tooting 550 MHz? Would be a bit of a bummer to think that you couldn't. > If someone knows a smarter way to design FPGAs, we really are > listening. Honest ! I don't want to design FPGAs, I want to use them better and not be re-creating the wheel either and I think darn near all of your users would too. The Xilinx way appears to be to avoid adhering to or encouraging any design standards for IP creation other than to imply that the X way is the only and the best way. > Our customers want performance at the lowest cost, plus ease-of-design. > But everybody has his own ideas about relative priorities. Yep KJArticle: 111547
Hi! There got to be a large number of owners of the $149 Spartan3E kit out there. I wonder if you have as little success as I if you try to perform a BPI (byte-wide peripheral interface) configuration of a basic MicroBlaze project built with BSB. Can you please try the following simple steps and see what happens: 1. Built simple basic MicroBlaze system using BSB with OPB_EMC controller for the Strataflash, DDR controller for the DDR_SDRAM and a uartlite. 2. Download the design via JTAG to make sure the automatically generated memory test application works. 3. Start a command prompt window and go to the implementation directory. You will find 2 bit-files. Download.bit and system.bit. Convert download.bit to a bin file with the following command: "promgen -p bin -c FF -o output.bin -u 0x0 download.bit". 4. Program the output.bin file at offset 0x2000 in the Intel Strataflash with the "device configuration -> program flash memory" option found in Xilinx Platform Studio. 5. After flash programming; Turn of power to the board. 6. Strap it for BPI_UP configuration mode "010" (Strap J30). 7. Turn power on again. Does the DONE LED turn on? Mine doesn't. If DONE lights up: Does the automatically generated memory test application start printing via uart_lite? Thanks! /JG http://www.xilinx.com/xlnx/xebiz/designResources/ip_product_details.jsp?key=HW-SPAR3E-SK-USArticle: 111548
Adnan wrote: > Sir you are right, I want to read configuration space(only BARS) of > another target. I don't think using the bridge in host mode is an option in a PC... As Andreas rightly pointed out, not only do you have to read config space of other cards, you also need to ensure IDSEL is generated. And as we both suggested, have your host driver probe the required information and explicitly write it to your card. It is the most practical and benign solution. Regards, -- Mark McDougall, Engineer Virtual Logic Pty Ltd, <http://www.vl.com.au> 21-25 King St, Rockdale, 2216 Ph: +612-9599-3255 Fax: +612-9599-3266Article: 111549
See whole thread at: http://groups.google.ca/group/comp.arch.fpga/browse_thread/thread/322e88de0fbb80e8/65ecc09c50ed8d9b?lnk=raot&hl=en#65ecc09c50ed8d9b Duane Clark wrote: > Jhlw wrote: > > It does seem to be my experience as a user with a couple of > > months of experience that project files need to be cleaned in ISE, > > too ... > > Unlike EDK, ISE has always correctly detected changes for me. I don't > "clean" the files there, and use the GUI to rebuild. It now seems good > enough for everyday use. OK; I think you have more experience on this than I do. I sent the following to the Xilinx customer service manager: Since you are a customer service manager, I wonder if you can help with the suggestion that I have below? There was a simple point that would have only taken a minute to explain to me, and would have saved me days and possibly up to a week or two. Today on my way in to my office, I helped a 50-60-something lady in the parking lot hold something that would have caused her a lot of inconvenience if it had blown away in the wind. Similarly, if somebody could have helped me as I suggest below, it would have saved me days, etc., of my time. Wouldn't it be nice if I could feel it a pleasure to help someone else rather than to have to grit my teeth and think, over and over, "If I help someone, what goes around will come around... If I help someone, what goes around will come around..." ?? Here is my message that I just sent (this CAE is a pretty good guy, in contrast with another guy from California, who was very selfish and uncaring (in a previous webcase, "FPGA tools do unexpected things" -- he ended up with a random guess designed to get rid of me and told me that he couldn't give me any more support because he had to close the web case "for statistics" (i.e., so he could look good))): Date: Nov 5, 2006 5:24 PM (-0500) Subject: Re: FW: WebCase "ACTUAL results DISAGREE with SIMULATOR results." Re: 8.2i XST - support of VHDL function Hi , My whole difficulty for which I needed this webcase was resolved by realizing that I had to do "Clean All Generated Files" in EDK, not only "Cleanup Project Files" in ISE (and according to the people on Usenet, doing it in ISE is not even necessary). This was why my results were not agreeing with simulation, because I wasn't building what I thought I was building. Today I realized what my bug was, in only a short time. It only took me a short time to debug my code, but it took me many days because I didn't know about "Clean All Generated Files" in EDK, and I wasn't getting results I could use to debug. This was very confusing, because it is in ISE in which it seems that all the generated files are being created, so I think that's what I have to clean, not EDK, because it just seems like it only creates "source" files. So I have two recommendations: 1. please put in a change request for the documentation and for EDK. Ideally EDK should just automatically delete its generated files when the user makes a change that requires them to be deleted. Where the documentation says: "The Clean All Generated Files command removes the generated files from a specific task. For example, the Platform Generation tool (Platgen), which is invoked using the Generate Netlist command, generates the netlist files from the source VHDL code. When you clean the process, the generated netlists are removed." (file:///C:/EDK/doc/usenglish/help/platform_studio/platform_studio.htm#html/ps_c_gst_whatsnew.htm) That is horrible rubbish, since that is the ENTIRE contents of that help page. Instead, it should say "You must do "Project -> Clean All Generated Files" after making changes to System Assembly, or your changes WILL NOT be recognized." But that is still not very good. A user should not have to search an obscure manual to find out about such an important step that will really hurt him like this if he doesn't know about it. The EDK should at least TELL the user with a message box that "Now Generated Files Should Be Cleaned" if it cannot do it automatically. Also, that help information should not just talk about "cleaning a process" with NO information about how you specify a process or DO the things it is talking about -- that is horrible user abuse. It is horrible abuse of the user to put in such an obscure bit of help "information" when a clear statement: "You must do "Project -> Clean All Generated Files" after making changes to System Assembly, or your changes WILL NOT be recognized." is what is needed. Please put in the simple, needed help information, first, and THEN, when you as a company have time, add the technobabble when you have time to add the complete explanation. Even so, with something like this, it is still horrible abuse of the user to have this only in the documentation; it should show as a message when EDK is used. Ideally the objective is that a user should not have to read a manual, because no one likes studying obscure and confusing fine print when they have a job that they have to be doing. I hope I am making myself very clear on this point.
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