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
We are looking at using SRAM FPGA's for first time and trying to get an approximate config time for say a XCV2P40 using the byte wide bus vs serial bus to minimize time after reset. Assuming we have to load 100% of the device can anyone provide an approximate config time? Are we talking micro , milli or seconds ? Also if the config time is too long are there any tricks that can be played to reduce it , short of removing functionality ? Thanks!Article: 101076
Thanks a lot for your answers. Actually, I can not tell you more about the size of the CAM. You are talking about the size but did you implement cam in Altera (Stratix?) because I didn't see it was possible to put cam in Stratix in Altera's website. Have a nice day. FreechipArticle: 101077
hi masters. this faq is very helpful. i need help!!! i'am currently doing verification of the zdut made in VHDL. i need to prepare testplan before i start. so if i get an idea how to make a testplan would be very helpfull. for example. i need to test a FIFO. this is just to make me understand. but i have to verify more complex designs. so if any one out here, can help me with this, keeping an FIFO as an example would be very greatfull. thanks Abbs...Article: 101078
freechip wrote: > Thanks a lot for your answers. > Actually, I can not tell you more about the size of the CAM. > You are talking about the size but did you implement cam in Altera > (Stratix?) because I didn't see it was possible to put cam in Stratix in > Altera's website. > Have a nice day. > > Freechip Right, right. My apologies. I'm just so used to having embedded LUT-style memories available that I have trouble making the mindset switch to Altera. In Altera, CAMs suck (except maybe for way back in the 20K days). You can still use the embedded memories to build up a CAM in segments for a small number of entries. Using the 4k memories arranged as 256x16, you could build 16 CAMs in 8-bit segments. 16 CAM entries of 128 bits would take 16 4k RAM blocks and qty 16, 16-wide cascades to indicate a byte match for all 16 memories for one CAM entry. So it can be done but with significantly more resources than the 64 slices needed in an SRL or single-port LUT-RAM device.Article: 101079
On 15 Apr 2006 18:39:28 -0700, "Peter Alfke" <alfke@sbcglobal.net> wrote: >Well, I'll try another attack on our demonstrated stupidity. >I have screamed and hollered for almost a year, and sent e-mails up the >ladder, up to one step below the very top. >Maybe I have to go one stop higher. >Steve Knapp and I are very frustrated about this situation. >Obviously, our company could do much better... >Peter Alfke, from home I'm glad you see it this way. Further ammunition, should you need it... Perhaps those who made the decisions based them on the quality of distributor service visible to themselves, i.e. in the USA. Which is fine if Xilinx don't want to be a global company. Worldwide, things may not be quite so good; a multi-national distributor like Avnet insists you (i.e. the customer) deal with their national division, who operate to nationally accepted standards. Which, in the case of the UK, means a quality of service somewhere between Fawlty Towers and the Dead Parrot sketch. Now I don't want to attack the idea of local distribution, and happily use it where I can. But (for just one real example) having been quoted a seven week lead time for a critical component, is it better to wait patiently with a stalled project, or order it online (ex-stock!) and continue working? - BrianArticle: 101080
I working on a design that uses an altera APF10K10ATC144-3 device. I have discovered some unusual long delays in a configuration where the input clock (50ns period ) signal at a global clock pin: a) directly feeds an output A b) passes through an inverter and feeds and output B According to the quartus II v4.2 sp1 simulator, the delay between the rising flank of the clock at the input and the rising edge of the output A is 15.3 ns (!) and, surprise, between rising clock and the falling edge of output B is 14.9 ns, i.e. output B is even faster (!). Since 15ns is an unusual delay I took the scope and measured, approximately 5 ns in both cases, the delay being obviously slightly less to output A than to output B. The question is, why is the simulation wrong? (Yes, I have selected the correct device in the assignments). I can understand that reality is always worse than simulation but have almost never the opposite! In any case, the simulator is almost useless in this case. Any suggestion is appreciated PereArticle: 101081
OK, 20 Gbit/s, thanks. Any input on whether max and argmax across 1,000 10-bit numbers will take up much space on the fpga in comparison to the space required for 1,000 100-bit adders? (I guess with 20 Gbit/sec they would be 100-bit and not 80-bit) Thanks, AndrewFArticle: 101082
oopere schrieb: > The question is, why is the simulation wrong? (Yes, I have selected the > correct device in the assignments). I can understand that reality is > always worse than simulation but have almost never the opposite! Wrong. Always the opposite. The delay values given by the manufacturer (and used in simulation) are guaranteed values under worst case conditions. For CMOS these usually are: - worst case input rise time (yes, gate delays depend on input slope) - The lowest allowed VCC - A rather high output loading (e.g. 50pF for PCI compliant outputs) - The highest allowed temperature - slowest chip on a wafer - slowest wafer produced over time If you have flip flops in your design: - worst case clock arrival time for on chip clock skew and jitter additionally for SOI chips: - worst case signal history (delay depends on the last couple of transitions) You are probably far away from worst case for most of these parameters, so you will always be faster in reality than in a worst case simulation. > In any case, the simulator is almost useless in this case. On the contrary. For virtually all applications the slowest edge behaviour is what you want to simulate. For all other applications you need to do monte carlo simulation. Kolja SulimmaArticle: 101083
andrewfelch@gmail.com schrieb: > OK, 20 Gbit/s, thanks. Any input on whether max and argmax across > 1,000 10-bit numbers will take up much space on the fpga in comparison > to the space required for 1,000 100-bit adders? (I guess with 20 > Gbit/sec they would be 100-bit and not 80-bit) As you produce less than one 10-bit number per clock cycle on average a single 10-bit maximum gate is sufficient. That's 10 LUTs. However, it depends on your algorithm wether you can skew the data processing in a ways that the intermediate results are produce one after. If you get them all at once, you also need 10000 Bits of storage. Kolja SulimmaArticle: 101084
Hi, I have a Xilinx ML401 board and need to use the USB ports provided to transfer data at high speed from the board to a PC. There is a Cypress CY7C67300 on the board which I believe is setup in standalone mode. So to use the ml401 only as a peripheral to transfer data to the pc, do I: 1) Need to change any of the Cypress USB controller settings. 2) How easy would it be to write some VHDL to use in ISE so that I can emulate a rs232 UART (but over USB2.0 at high speeds). Thank you in advance for your help, AlArticle: 101085
Rick,
Thanks for the compliment.
Austin
rickman wrote:
> As long as you brought up your personality, I'll just say that I
> remember reading about someone who reminds me of you, Napoleon. He
> thought a lot of himself too.
>
> Austin Lesea wrote:
>
>>Rick,
>>
>>Well, I hope you keep up the comments.
>>
>>I am seriously trying to improve the documentaion process.
>>
>>If we explain it right the first time, we get less confusion, and we get
>>to market faster.
>>
>>Really very simple, and very self serving: the better the docs, the
>>less time wasted, and the faster our customers either gain success, or
>>fail. The faster money changes hands. The faster we succeed (or fail
>>to succeeed).
>>
>>It is so simple, yet so many (most) companies get it wrong.
>>
>>Just make it simple to succeed, and don't get in the way, or make things
>>any tougher than they already are.
>>
>>As for my personality, my wife thinks I am completely impossible ('how
>>can anyone work for you?'). My staff thinks I am the best boss they
>>every had ('how can your boss deal with you?'). My supervisors love
>>that I always come to them with a solution to the problem ('how do you
>>keep your people so happy?'). My (totally grown) kids claim I am
>>totally mad, and can not be trusted even for a moment ('that's not
>>fair!'). My grandchildren sense I can be completely trusted to see to
>>their well being and happiness (which I can be).
>>
>>So, I have a personality: guilty as charged. Member of the human race.
>>
>>Austin
>
>
Article: 101086From the table in the Virtex-II Pro user guide, Configuration, Configuration details, the approximate SelectMAP programming time for an XC2VP40 at 50 MHz is 39.67 ms. This is an older data sheet version I'm looking at, so please verify the numbers yourself. "Jerome" <jerome_l_horowitz@yahoo.com> wrote in message news:1145968082.165505.144810@i39g2000cwa.googlegroups.com... > We are looking at using SRAM FPGA's for first time and trying to > get an approximate config time for say a XCV2P40 using the byte > wide bus vs serial bus to minimize time after reset. Assuming we > have to load 100% of the device can anyone provide an approximate > config time? Are we talking micro , milli or seconds ? > > Also if the config time is too long are there any tricks that can be > played > to reduce it , short of removing functionality ? > > Thanks!Article: 101087
Hi All,
Just wanted to know if anyone has experienced any problems with Xilinx
XST when declaring a constant record in VHDL.
Below is some, what I hope to be valid, VHDL, that makes XST fail and
spit out a Internal Error. I'm using ISE 7.1 (SP4) running on a Linux Box.
Is this really an XST bug/problem/deficiency? Would be great to hear
from any 8.1 users to see if this is still a problem.
The Error:
INTERNAL_ERROR:Xst:cmain.c:3022:1.146.4.1 - To resolve this error,
please consult the Answers Database and other online resources at
http://support.xilinx.com
The VHDL:
library ieee;
use ieee.std_logic_1164.all;
use ieee.numeric_std.all;
entity Test is
end entity Test;
architecture General of Test is
type SNAPTYPE_ALU_FLAGS is record
zero : std_logic;
negative : std_logic;
carryBorrow : std_logic;
overflow : std_logic;
end record SNAPTYPE_ALU_FLAGS;
type SNAPTYPE_INTERNAL_FLAGS is record
aluFlags : SNAPTYPE_ALU_FLAGS;
equalityTests : std_logic_vector(2 downto 0);
globalInterruptEn : std_logic;
end record SNAPTYPE_INTERNAL_FLAGS;
constant SNAP_FLAGS_RESET : SNAPTYPE_INTERNAL_FLAGS :=
((zero => '0', negative => '0', carryBorrow => '0', overflow => '0'),
equalityTests => b"000", globalInterruptEn => '0');
begin
end General;
Cheers
Andy
--
Dr. Andrew Greensted Department of Electronics
Bio-Inspired Engineering University of York, YO10 5DD, UK
Tel: +44(0)1904 432379 Mailto: ajg112@ohm.york.ac.uk
Fax: +44(0)1904 433224 Web: www.bioinspired.com/users/ajg112
Article: 101088Jerome, http://direct.xilinx.com/bvdocs/userguides/ug012.pdf See chapter 4. There are 15,868,192 bits in the bitstream for a V2P40. In the parallel modes of configuration, you can clock in 8 bits at a time. http://direct.xilinx.com/bvdocs/publications/ds083.pdf page 108 lists 66 MHz as the max CCLK. So, with some math, gives 30 milliseconds to configure. 15,868,192/(8*66,000,000)=.0301 seconds That is after the power on reset (part has reached all of its proper operating voltages). One trick is to use the compressed bit stream option which will copy identical columns of memory (if there are any). Depends on your design. If your design is very regular, you might gain significantly here. Austin Jerome wrote: > We are looking at using SRAM FPGA's for first time and trying to > get an approximate config time for say a XCV2P40 using the byte > wide bus vs serial bus to minimize time after reset. Assuming we > have to load 100% of the device can anyone provide an approximate > config time? Are we talking micro , milli or seconds ? > > Also if the config time is too long are there any tricks that can be > played > to reduce it , short of removing functionality ? > > Thanks! >Article: 101089
Yeah the boot code pretty much copies the program to SDRAM, loads the jump address and jumps. I modified the code to include the isync/sync instructions: <program copied to SDRAM> <Cache is cleared - cache is already disabled> 0xffffca30 main+0x25c: 4c00012c isync 0xffffca34 main+0x260: 7c0004ac sync 0xffffca38 main+0x264: 7c0903a6 mtctr r0 <entryPt> 0xffffca3c main+0x268: 4e800421 bctrl The code still halts as it did before. Thanks for the idea.Article: 101090
Kolja Sulimma wrote: > oopere schrieb: > > > The question is, why is the simulation wrong? (Yes, I have selected the > > correct device in the assignments). I can understand that reality is > > always worse than simulation but have almost never the opposite! > > Wrong. Always the opposite. > The delay values given by the manufacturer (and used in simulation) are > guaranteed values under worst case conditions. For CMOS these usually are: > - worst case input rise time (yes, gate delays depend on input slope) > - The lowest allowed VCC > - A rather high output loading (e.g. 50pF for PCI compliant outputs) > - The highest allowed temperature > - slowest chip on a wafer > - slowest wafer produced over time > > If you have flip flops in your design: > - worst case clock arrival time for on chip clock skew and jitter > > additionally for SOI chips: > - worst case signal history (delay depends on the last couple of > transitions) > > You are probably far away from worst case for most of these parameters, > so you will always be faster in reality than in a worst case simulation. > > > In any case, the simulator is almost useless in this case. > > On the contrary. For virtually all applications the slowest edge > behaviour is what you want to simulate. > For all other applications you need to do monte carlo simulation. > > Kolja Sulimma Thank you. I understand your points. I did not take into account that I am simulating the worst case scenario. However, a) I still wonder if 15ns is a reasonable worst-case delay for a direct input to output connection (or for an input->not gate->output connection) for this kind of device. I have been trying to figure out which combination of t_xyzk?#? from the datasheet I should be adding in this case (have to say, without success) b) It is surprising that the simulator tells that the direct connection exhibits greater delay than the inverted one. Perhaps this depends on which particular output pin is driven? Any comments, anyone? PereArticle: 101091
> I working on a design that uses an altera APF10K10ATC144-3 device... Sorry, this should be a Flex10K "EPF 10K10ATC144-3" deviceArticle: 101092
Hi Charles,
<charles.eddleston@gmail.com> wrote in message
news:1145916923.510303.247000@j33g2000cwa.googlegroups.com...
>
> I've been struggling to get the Xilinx IOCM and DOCM modules working
> with the PPC405 in my current design and I'm starting to run out of
> ideas. The first iteration of the design uses cached SDRAM via the PLB
> to store/load the boot code and runs without issue. Since the design
> is starting to get full (running out of LUTs, but BRAMs are available),
> it was decided that it might be worthwhile to use the OCM interface to
> cut down on logic. The OCM should be the perfect solution because the
> boot code is currently only called once and then code executes out of
> SDRAM.
Sounds like a bit of a puzzle. I do recall hitting a slight problem with the
OCM before: the instruction-side OCM is completely hidden from the
processor's data read/write path. So if your program tries to read
0xFFFFC000 - 0xFFFFFFFF it will not see its own code.
I can't see how this would be causing you problems though... particularly as
you say you've seen the first packet of instructions being fetched from the
SDRAM, so the OCM should really be out of the picture at that point. (I
can't remember exactly why this caused *me* problems; I think it was
something to do with the way the standard library was compiled that it had
some data stored in the code space, which could never be accessed.)
So my suggestion is, why not dump the OCM entirely and use a small chunk of
initialized BRAM attached to the PLB as your boot ROM instead? Perhaps there
is a little overhead in terms of decode logic vs. OCM, but probably not so
very much.
Cheers,
-Ben-
Article: 101093Hi there, I have a low frequency variable clock frequency (for vari-speed audio tasks) in the range of 39 KHz to 50 KHz. Is it easy within an FPGA to implement a 32 times clock multiplier? Would the circuit be a combination of PLL's? Any advice/help appreciated! Thanks, Bob.Article: 101094
Hi Andrew,
"Andrew Greensted" <ajg112@ohm.york.ac.uk> wrote in message
news:e2lf63$k5h$1@pump1.york.ac.uk...
> Hi All,
> Below is some, what I hope to be valid, VHDL, that makes XST fail and
> spit out a Internal Error. I'm using ISE 7.1 (SP4) running on a Linux Box.
> <snip>
> constant SNAP_FLAGS_RESET : SNAPTYPE_INTERNAL_FLAGS :=
> ((zero => '0', negative => '0', carryBorrow => '0', overflow => '0'),
> equalityTests => b"000", globalInterruptEn => '0');
Have you tried using named association for that first parameter? i.e.
constant SNAP_FLAGS_RESET : SNAPTYPE_INTERNAL_FLAGS :=
(aluFlags => (zero => '0', negative => '0', carryBorrow => '0', overflow
=> '0'),
equalityTests => b"000", globalInterruptEn => '0');
Both are legal, but synthesis tools are known to take exception to the
slightest unexpected things...
-Ben-
Article: 101095shailbadwaik@gmail.com wrote: > I am working on MAC802.3 & not getting How to get divider in CRC32 ? http://groups.google.com/groups/search?q=vhdl+crc32Article: 101096
Robin Bruce wrote: > SRC are talking about the following characteristics for a > field-programmable floating-point device that they intend to put in one > of the variants of their SRC-7 reconfigurable computer: > > Hard floating point units with field-programmable interconnect > > >>50 DPFP mults and adders per chip -> 30 GFLOPS > > >>100 SPFP mults and adders per chip -> 60 GFLOPS > > > Each FP unit also performs 53 or 24 bit integer ops with 106 or 48 bit > results > > Selectable 150 MHz or 300 MHz operation > > I've heard that these units will have single-cycle latency. I don't > imagine that these FPGAs will be cheap as there must be considerable > NRE costs that won't be recouped so easily as they would be for a > Xilinx chip. However, they open up a whole new world of possibilities > for scientific computing, making double-precision much more viable than > it has been previously. > > Is this the device reconfigurable computing has been waiting for? > Not really. I remember 25 years ago there was a Weitek FPU to be had external to a cpu. Even though it was much faster than the 8087, the 8087 won, especially after it was integrated into the 80386. Now, you can make your own FPU with an FPGA. You can define where you want the silicon spent on. Everything single cycle may not be optimal, it may be overkill. Rather have certain stages pipelined but have three FPUs instead. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 101097
dancedynamix@hotmail.com wrote: > Hi there, > > I have a low frequency variable clock frequency (for vari-speed audio > tasks) in the range of 39 KHz to 50 KHz. > > Is it easy within an FPGA to implement a 32 times clock multiplier? > > Would the circuit be a combination of PLL's? > > Any advice/help appreciated! These frequencies are a bit on the low side. Yes, it may possibly be done with an FPGA, after dividing the clock down. A normal PLL may be the better solution though. Rene -- Ing.Buero R.Tschaggelar - http://www.ibrtses.com & commercial newsgroups - http://www.talkto.netArticle: 101098
ziggy (ziggy@fakedaddress.com) wrote: : Just ran across this today, really inexpensive... Wonder how it stacks : up to the 'free' tools from xilinx? ( im not qualified to do a review ) : Their Hypercomputing things look really cool, but wont even ask how much : they cost :) As far as I know it doesn't "stack up against" the tools from Xilinx so much as stack up on top of the Xilinx tools... Otherwise it looks like a schematic tool, a set of libraries, some abstraction layers and some hardware. Oh and a misunderstanding of polymorphism... --- cdsArticle: 101099
Robin Bruce wrote: > I suppose it would make sense to change the charter of this newsgroup > to reflect usage. Joking aside, c.a.f pretty well reflects how the > majority of FPGAs are actually used, so I wouldn't make the case that > there's anything wrong with the group. I suppose I believe that there's > more interest in reconfigurable computing than is being suggested by > the volume of posts here. Maybe the best thing for me to do in the > short run is to try and start up a few reconfigurable-computing posts > here and see what happens. > > Robin That's probably true, but somehow seems to defeat the sense of order that the usenet folks setup to catorgize topics/groups. There are other places for electronics, engineering, and product support for those. Comp.arch just isn't the place for VHDL/Verilog training and support, particularly for vendor specific issues. Nor is circuit level design, interfacing, etc really an computer architecture topic for custom hardware. Even partial reconfiguration for most hardware projects, isn't on topic, although a related technology for this group. SoC, reconfigurable computing, and even hardware designs for building fpga computers would be on topic for a comp.arch rooted group.
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