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
One thing you can do is to identify blocks and try and size those. If the function is something you could buy an IP for then have a look at datasheets for those products to get an idea on size. There are a lot of IP products listed with datasheets on the Xilinx and Altera etc websites. If it something else you can always give some more details to the group and someone will probably have an idea on size. From the design end certain things will limit your selection like the numbers of I/O needed or features like RAM, flops, luts etc. As said elsewhere it is worth planning contingency - don't start with the expectation of fully using the largest device in a given footprint. Go mid-range as expectation but have the bigger parts in mind as project savers. We use the Spartan-3s in a FG456 package a lot in our products and there is 4 sizes available with a notional size spread of x5 so you can have a wide range in size. Most Xilinx packages have a choice of size and there is a nice table near the end of section1 of the datasheet showing what is available. Failing all of that just get stuck in and build some modules to run through the tools and get some real sizes. -- John Adair Enterpoint Ltd. - Home of Broaddown2. The Ultimate Spartan3 Development Board. http://www.enterpoint.co.uk "Pravin G" <gavatepravin@rediffmail.com> wrote in message news:ee9c84b.-1@webx.sUN8CHnE... > Hi all, > > We want to implement a design in a spartan - 3. and select a device (in > terms of system gates) at the initial stage of the project. > > Is there any method for this.Article: 104201
"Alex" <alexmchale@gmail.com> wrote in message
news:1150821352.453929.125790@c74g2000cwc.googlegroups.com...
> Yes, I am indeed using XST. Where is this "add I/O pads" option within
> ISE?
Process Properties for XST | Xilinx Specific Options | Add I/O Buffers
(should be checked).
Cheers,
-Ben-
Article: 104202
Hello Manfred,
We have investigated this and discovered that the message"Critical
Warning: Ignored Power-Up Level option on the following nodes --..." is a
side effect of a Quartus bug. This bug occurs if there is a State Machine
Synthesis with the following conditions:
1. The State Machine is specified in VHDL.
2. The State Machine inferred by Quartus Integrated Synthesis (quartus_map)
does NOT have a reset signal in it.
3. State Machine Processing is set to either Auto or One-Hot
4. Quartus II 6.0 is being used.
If your state machine has a reset in it you can ignore this message. Your
design will provide expected results on the board. If your state machine
does not have a reset you will need to add a reset to it, else it will not
work on the board. This bug exists in Quartus II 6.0 only. It has been fixed
in Quartus II 6.0 SP1 which will be released early next week (about June
24th, 2006).
We apologize for any inconvenience this may have caused.
Hope this helps,
Subroto Datta
Altera Corp.
"Manfred Balik" <manfred.balik@tuwien.ac.at> wrote in message
news:4497dc62$0$8024$3b214f66@tunews.univie.ac.at...
>I compiled my Design with the new version 6.0 of Quartus and get much more
>Warnings :-(
> Especially a Critical Warning of the Fitter disconcerts me:
>
> Critical Warning: Ignored Power-Up Level option on the following nodes --
> nodes are set to power up low
> Critical Warning: I/O cell
> "i2c_core:inst33|i2c_master_top:inst|i2c_master_byte_ctrl:byte_ctrl|i2c_master_bit_ctrl:bit_ctrl|c_state.idle"
> will power-up low
> Critical Warning: I/O cell "i2c_control:inst32|i2c_todo.test_i2c" will
> power-up low
> Critical Warning: I/O cell
> "i2c_control:inst32|i2c_state.write_i2c_core_reg" will power-up low
> Critical Warning: I/O cell
> "i2c_core:inst33|i2c_master_top:inst|i2c_master_byte_ctrl:byte_ctrl|\statemachine:c_state.st_idle"
> will power-up low
>
> This I/O cells are the states of the state machines. How can the state
> machines be in the right state if the power-up level is not correct
> initialized ???
> The new compilation works anyway!!!
> Can someone explain it to me???
>
> Thanks, Manfred
>
>
Article: 104203Thanks KJ, I have forgotten to say: there is no initial value assigned in the declaration :-((( The code is written correctly (I have checked it, because it's not written by me), and I'm using the same structures you described in my own codes for years ... but this critical warning is new since Quartus 6.0 :-((( and today I have compiled the project several times and it works fine on the FPGA every time! "KJ" <kkjennings@sbcglobal.net> schrieb im Newsbeitrag news:9l9mg.47540$fb2.34992@newssvr27.news.prodigy.net... > It's generally a good idea to understand the source of a 'critical' > warning...actually not a bad practice to understand the source of 'not so' > critical warnings too. You didn't say whether the place in the code where > the signal is actually declared has an initial value assigned to it. Look > for the place where the signal is declared and see if it looks anything > like... > > signal Current_State: t_The_States := Idle; <--- This would be an > initialization that would get ignored if you have it. > > Usually, initial values of any sort are not synthesizable (i.e. each of > the following statements) > signal slv: std_logic_vector(7 downto 0) := "10101010"; > signal Counter: natural range 0 to 255 := 200; > > If you do have initial value assignments like these, then the reason for > the warning is because this is the type of code where simulation results > will differ from actual results. The above statements are all legal VHDL > and any simulator will initialize the signals exactly the way they are > defined to be at t=0. If the targetted device does not support power up > default values (and generally they don't other than some devices do > guarantee to power up all flops at '0') than the behaviour of the real > part will differ from that in simulation. Whether or not you simulate, > keep in mind that someone down the line who inherits your code might so > what you should do is purge any and all initial value declarations in your > code that are not synthesizable to your target device and do not conform > to what the device actually does. > > Even if the initial values is '0', that initial value assignment can > likely be purged from the code even though technically they are > synthesizable when targetting a device that guarantees flops to initialize > to '0'. In that particular situation I wouldn't expect that you should > get any warning since the part does in fact grant you your wish of an > initial value. What it also does though is limit your code to devices > that do give you that guarantee. There are occasional times when an > initial value assignment is actually needed but not too often. So if your > design doesn't reeeeeally need the initial value then best just to purge > it and not limit the universe of possible targetted devices without good > reason > > KJ >Article: 104204
In that case, that did not solve the problem. That was already enabled. Any other thoughts? This is a complete road block for me in development. I just don't understand why this thing won't work with anything more complicated than directly wiring the switch to the LED. I can send a zip of my project to anyone willing to help. I'm using Xilinx 8.1i WebPACK, with the latest service pack. Thank you. Alex McHale Ben Jones wrote: > "Alex" <alexmchale@gmail.com> wrote in message > news:1150821352.453929.125790@c74g2000cwc.googlegroups.com... > > Yes, I am indeed using XST. Where is this "add I/O pads" option within > > ISE? > > Process Properties for XST | Xilinx Specific Options | Add I/O Buffers > (should be checked). > > Cheers, > > -Ben-Article: 104205
One way of obtaining this information in Quartus II 6.0 is to create a project, assign the device that you want to use (Assignments->Device), open the Pin Planner (Assignments->Pin Planner) and in the All Pins View (this is the table in the lower half of the screen) customize the columns using the following steps: 1. Right click in the All Pins View->Customize Columns..., and add the General Function Column. The Genaral Function column will show if it is Row I/O or Column I/O. 2. Right click in the All Pins View and click on the Show Assignable Pins. This will show all pins on the package. You can order the columns displayed in step 1. You can then copy and paste this information into Excel or your favorite document format. Hope this helps, - Subroto Datta Altera Corp. <rreuter@gmx.net> wrote in message news:1150877340.814578.94120@g10g2000cwb.googlegroups.com... > An Altera application note (AN-349) recommends placing certain outputs > on column pins and others on row pins. My question is: which pins of > the Stratix device are column and which are row pins? Is there a > document that includes this info? I assume that the assignment is fixed > and given by architecture, not dynamically? > > Thanks for advices, Roland. >Article: 104206
Delving a bit deeper, I see that I am getting the following warnings before the final error. When I disable "Add I/O Buffers," I get these warnings on all of my lines. When it is enabled, I only get it for my CLOCK. While I'm sure my net list is correct, this must be a symptom of the issue that's preventing my vhdl to load. Any ideas? WARNING:NgdBuild:483 - Attribute "LOC" on "CLOCK" is on the wrong type of object. Please see the Constraints Guide for more information on this attribute. WARNING:NgdBuild:483 - Attribute "IOSTANDARD" on "CLOCK" is on the wrong type of object. Please see the Constraints Guide for more information on this attribute.Article: 104207
Hi Actel FUSION kit that I had ordered in DEC 2005 (was supposed to be off-the-shelf !) arrived today. Only 6 months delay. Havent have time to play yet, only powered the board, the Analog Digital converter in the FPGA defenetly works as analog valtage from an poti is displayed on the LED's. AnttiArticle: 104208
Hi all, I am using PowerPC on Virtex II Pro. The whole program is bigger than the cache, I suspect though that most of the times only a portion of the code is used that would fit into the cache. Is there a way I could ensure that this part of my code is so compiled that it could be all loaded into the cache at a time? I welcome any sugestions. Regards, e.Article: 104209
I'm not sure I understand how your simplified state table optimization is going to find identical sequences of states, since the individual states do not have identical from's and to's compared to any other individual states, but the sequence as a whole may be identical to another sequence as a whole. It seems to me that this is where the most redundant states are going to be found. In software, they usually write these identical sequences as subroutines, perhaps we should focus on the same, and use sub-state-machines. Finding identical sequences is a little harder. OTOH, someone smarter than me has probably figured it all out... I've designed a lot of FPGAs, and never had need for more than 20 states, with the vast majority less than 8. With that number of states, the Mark II eyeball optimizer works pretty well. Andy backhus wrote: > Hi everybody, > thanks to everyone for their contributions. > > Some of you mentioned that state minimization rarely improves most FSMs, > except the mentioned decision-tree example type. I made the same > experiences and agree to that. > > The surprising point for me was that state expansion also is a method to > get faster and/or smaller results. > > Some mentioned a large increase of synthesis runtime due to a state > minimization algorithm. I don't think so. My experience with dc is that > it's done almost instantly (on a 400 MHz Sparc) and most of the time is > spent for writing messages to the screen. In fact, after extracting the > FSM into a state table the algorithm just needs to sort that table, look > for equivalent outputs and next states to be eliminated and rearrange > the next-state entries to the remaining collapsed state. > I think synthesis tools already have much more complex algorithms > working than this one. > State expansion could be much more complicated, since it needs a > area/timing estimation to calculate the benefits of creating aditional > states. > > > Jim feared that during state minimization time keeper or wait states > could be eliminated. Definitely not. The next-state of a wait state is > never equal to any other state, so it can't be eliminated. > > About how and when such an algorithm should be applied... > Well, like most special features of an EDA tool it should have a control > flag, either by command line or GUI. In dc, to answer Mikes question, > every step is performed by a separate command. Like this: > > --- > compile -map_effort medium <- performs an initial optimization > extract <- finds the FSM > set_fsm_minimize true <- enables the state minimization > compile -map_effort medium <- optimize again > --- > > Best regards > EilertArticle: 104210
Alex wrote:
> While I'm sure my net list is correct, this must be a symptom of the
> issue that's preventing my vhdl to load.
>
> Any ideas?
Get a vhdl simulator and learn to use it.
-- Mike Treseler
Article: 104211eascheiber@yahoo.com wrote: > Hi all, > > I am using PowerPC on Virtex II Pro. The whole program is bigger than > the cache, > I suspect though that most of the times only a portion of the code is > used that would > fit into the cache. Is there a way I could ensure that this part of my > code is so compiled > that it could be all loaded into the cache at a time? I welcome any > sugestions. The cache should work this out for itself. No need for you to tell it. Cheers, JonArticle: 104212
Antti wrote: > Actel FUSION kit that I had ordered in DEC 2005 (was supposed to be > off-the-shelf !) arrived today. Only 6 months delay. More than twice as quick as the FX40's I wanted then... Cheers, JonArticle: 104213
Eric wrote: > ... > I've created the sf project as xc3sprog -- I think with all these > additions we've expanded the program a bit from what its original > purpose was, but there seems to be no harm in keeping the name. > > Evidently SF will be contacting me in a day or two saying they've set > up the project, at which point I'll upload the code and we can start > accepting patches. Does anyone else want admin bits on the site? > ...Eric Eric, Any news from sourceforge ? http://xc3sprog.sourceforge.net/ seems not available... is the rigth address ? SandroArticle: 104214
Not that I don't appreciate your brilliant insight, but all of the above has simulated just fine. The problem is in actually implementing it. I'm having a software issue, somewhere, and the question is.. where. Thanks, though. You're a real gentleman . Mike Treseler wrote: > Alex wrote: > > > While I'm sure my net list is correct, this must be a symptom of the > > issue that's preventing my vhdl to load. > > > > Any ideas? > > Get a vhdl simulator and learn to use it. > > -- Mike TreselerArticle: 104215
backhus wrote: > In dc, to answer Mikes question, > every step is performed by a separate command. Like this: > compile -map_effort medium <- performs an initial optimization > extract <- finds the FSM > set_fsm_minimize true <- enables the state minimization > compile -map_effort medium <- optimize again Thanks. Score one for dc. Curious that Synopsys can cover such complex algorithms, but can't unwind a simple procedure without arguments. -- Mike TreselerArticle: 104216
Morten Leikvoll wrote: > Error from vcom: Attribute "event" requires a static signal prefix. > Xst handles this very nice.. Synthesis with Synopsys DC is even worse. It does not even allow my_gen: if N in 0 to 7 generate ... if rising_edge(clock_vector(N)) then ... end generate; > Are there any tricks around this, except the obvious "remove the > procedure"... You could select the clock-signal out of the vector before calling the procedure. Then you feed only the selected signal to the procedure. > PROCEDURE TRIGRD ... > BEGIN ... > elsif(INP(reg*8+bt)'event and INP(reg*8+bt)='1') then ... > elsif(INP(reg*8+bt)'event and INP(reg*8+bt)='0') then > END TRIGRD; Hmm ... dual-edge behavior? Do you want to model synthesizable code? Have a look at http://www.ralf-hildebrandt.de/publication/pdf_dff/pde_dff.pdf if you really need it and want to be independent from the tools. RalfArticle: 104217
Alex (alexmchale@gmail.com) wrote: : Delving a bit deeper, I see that I am getting the following warnings : before the final error. When I disable "Add I/O Buffers," I get these : warnings on all of my lines. When it is enabled, I only get it for my : CLOCK. : While I'm sure my net list is correct, this must be a symptom of the : issue that's preventing my vhdl to load. : Any ideas? : WARNING:NgdBuild:483 - Attribute "LOC" on "CLOCK" is on the wrong type : of : object. Please see the Constraints Guide for more information on : this : attribute. Perhaps you might want ro refer to the Constraints Guied as mentioned in the warning? It might prove instructive. Synchronous clocks are routed on dedicated clock nets, and if you're not brining the clock into the device on a dedicated clock input pin then things won't work as it is not possible to directly connect the "CLOCK" net to a non clock pin. You'll need to insert the correct buffer. cds : WARNING:NgdBuild:483 - Attribute "IOSTANDARD" on "CLOCK" is on the : wrong type of : object. Please see the Constraints Guide for more information on : this : attribute.Article: 104218
Andy wrote: > I've designed a lot of FPGAs, and never had need for more than 20 > states, with the vast majority less than 8. That has been my experience as well. Most controllers are pretty simple. The larger examples I have seen are cluttered attempts to fit all the process variables into a single enumeration. Separate variables for counters and shifters make a much cleaner description. -- Mike TreselerArticle: 104219
Alex wrote: > Not that I don't appreciate your brilliant insight, but all of the > above has simulated just fine. Sorry, I missed that point. I'll try your code on ISE and quartus when I get to work. -- Mike TreselerArticle: 104220
Dear All, I'm having a strange problem with my design that is driving me nuts... I'm a newcomer to FPGA in general and to Xilinx tools in particular. I'm using a Spartan-3 starter kit board with a XC3S200FT256 FPGA and ISE & EDK 7.1. My idea is to use the board as a controller for my hardware project. I've started with one of EDK's reference designs (Spartan-3 MicroBlaze Example Design) and change it to meet my specifications. My present configuration in: - microblaze - 16 KB block RAM - RS232 (OPB_UARTlite) - 8 LEDs (OPB_GPIO) - OPB_Timer - 3 pushbuttons (OPB_GPIO) - 8 DIP switches (OPB_GPIO) - 1 custom IP core to drive the 7-segments LEDs on the board - 1 custom IP core to drive a 2x16 LDC display - 1 custom IP core to generate a 5 MHz ADC clock, by dividing the on board 50 MHz clock, and to read 32 inputs from 4 8 bits ADCs. - 1 32 bit GPIO instance, configured as all inputs. - 1 32 bit GPIO instance, configured as all outputs. The design compiles OK and I don't get any error message, at least as far as I can tell. Now, here is the strange part: - If I connect all the modules to pins in the FPGA, using, of course, the .UCF file, the code does not run. It freezes after only a few lines. The first line of my code is a printf statement, and only a few characters are sent to the uart. After that, noting else happens. - If I comment, in the UCF file the, lines connecting the output GPIO to the FPGA pins, the program runs as it is suppose to run (the input GPIO is, for now, commented). Note that this behavior does not depend on what the code does. It may be the complet code with the initiation and write/read instructions, or it may be a simple "hello world" program. It doesn't matter. I have read the documentation on the FPGA, to see if I was using somme pins that I was not suppose to use, and I have also read the GPIO specification, but could not find any hint on what the origine of my problem is. What am I missing here? I must be doing a really stupid error, but I can't find it. I'm sure this is not a problem with the code, so it must be a problem in the design, but i'm not sure what kind of hardware debugging techniques I should use in this case. I'm posting the UCF below and I would appreciate any kind of help, hint, suggestion, etc. Tanks to all, Jos=E9 Mariano PS: Sorry for the lousy spell and the long post!! ############################################################################ ## This system.ucf file is generated by Base System Builder based on the ## settings in the selected Xilinx Board Definition file. Please add other ## user constraints to this file based on customer design specifications. ## ## Test version: ADC clock generated by IP and data read by IP ## ############################################################################ Net sys_clk_pin LOC=3DT9; Net sys_rst_pin LOC=3Dl14; ## System level constraints Net sys_clk_pin TNM_NET =3D sys_clk_pin; TIMESPEC TS_sys_clk_pin =3D PERIOD sys_clk_pin 20000 ps; Net sys_rst_pin TIG; ########################################################## ## FPGA pin constraints ########################################################## ## RS-232 Net fpga_0_RS232_RX_pin LOC=3Dt13; Net fpga_0_RS232_TX_pin LOC=3Dr13; ## LEDs Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<0> LOC=3Dk12; Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<1> LOC=3Dp14; Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<2> LOC=3Dl12; Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<3> LOC=3Dn14; Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<4> LOC=3Dp13; Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<5> LOC=3Dn12; Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<6> LOC=3Dp12; Net fpga_0_LEDs_8Bit_GPIO_d_out_pin<7> LOC=3Dp11; ## Push Buttons Net fpga_0_Push_Buttons_3Bit_GPIO_in_pin<0> LOC=3Dl13; Net fpga_0_Push_Buttons_3Bit_GPIO_in_pin<1> LOC=3Dm14; Net fpga_0_Push_Buttons_3Bit_GPIO_in_pin<2> LOC=3Dm13; ## DIP Switches pin constrains Net DIP_Switches_8Bit_GPIO_in<0> LOC=3Dk13; Net DIP_Switches_8Bit_GPIO_in<1> LOC=3Dk14; Net DIP_Switches_8Bit_GPIO_in<2> LOC=3Dj13; Net DIP_Switches_8Bit_GPIO_in<3> LOC=3Dj14; Net DIP_Switches_8Bit_GPIO_in<4> LOC=3Dh13; Net DIP_Switches_8Bit_GPIO_in<5> LOC=3Dh14; Net DIP_Switches_8Bit_GPIO_in<6> LOC=3Dg12; Net DIP_Switches_8Bit_GPIO_in<7> LOC=3Df12; ## 7 seg LED Display Net digit<3> LOC=3Dd14; Net digit<2> LOC=3Dg14; Net digit<1> LOC=3Df14; Net digit<0> LOC=3De13; Net segment<7> LOC=3De14; Net segment<6> LOC=3Dg13; Net segment<5> LOC=3Dn15; Net segment<4> LOC=3Dp15; Net segment<3> LOC=3Dr16; Net segment<2> LOC=3Df13; Net segment<1> LOC=3Dn16; Net segment<0> LOC=3Dp16; ## LCD NET LCD_Data<7> LOC=3Dn8; ## 14 NET LCD_Data<6> LOC=3Dn7; ## 13 NET LCD_Data<5> LOC=3Dt8; ## 12 NET LCD_Data<4> LOC=3Dr6; ## 11 NET LCD_Data<3> LOC=3Dt5; ## 10 NET LCD_Data<2> LOC=3Dr5; ## 9 NET LCD_Data<1> LOC=3Dc2; ## 8 NET LCD_Data<0> LOC=3Dc1; ## 7 NET LCD_E LOC=3Db1; ## 6 NET LCD_RS LOC=3Dm10; ## 4 ##NET LCD_RW LOC=3Dm7; ## gnd on the digital board ## GPIO - General purpose output NET GPIO_Output_GPIO_d_out<0> LOC=3Db8; ## BW0->SwD1 NET GPIO_Output_GPIO_d_out<1> LOC=3Db6; ## BW1->SwD3 NET GPIO_Output_GPIO_d_out<2> LOC=3Db7; ## BW2->SwD4 ## GPIO - General purpose input ##NET GPIO_Input_GPIO_in<0> LOC=3Dxx; ##NET GPIO_Input_GPIO_in<1> LOC=3Dxx; ##NET GPIO_Input_GPIO_in<2> LOC=3Dxx; ##NET GPIO_Input_GPIO_in<3> LOC=3Dxx; ##NET GPIO_Input_GPIO_in<4> LOC=3Dxx; ##NET GPIO_Input_GPIO_in<5> LOC=3Dxx; ##NET GPIO_Input_GPIO_in<6> LOC=3Dxx; ##NET GPIO_Input_GPIO_in<7> LOC=3Dxx; ## ADC's - INTEGRATOR IP ## ADC_0 -> In_Port[0:7] ## ADC_90 -> In_Port[8:15] ## ADC_180 -> In_Port[16:23] ## ADC_270 -> In_Port[24:31] ############################ NET fpga_INTEGRATOR_ENCODE_pin LOC=3Da5; ## ENCODE - ADC's Clock NET fpga_INTEGRATOR_ADC0_pin<0> LOC=3De10; NET fpga_INTEGRATOR_ADC0_pin<1> LOC=3Dc12; NET fpga_INTEGRATOR_ADC0_pin<2> LOC=3Dc11; NET fpga_INTEGRATOR_ADC0_pin<3> LOC=3Db14; NET fpga_INTEGRATOR_ADC0_pin<4> LOC=3Db13; NET fpga_INTEGRATOR_ADC0_pin<5> LOC=3Db12; NET fpga_INTEGRATOR_ADC0_pin<6> LOC=3Da10; NET fpga_INTEGRATOR_ADC0_pin<7> LOC=3Da9; NET fpga_INTEGRATOR_ADC90_pin<0> LOC=3De6; NET fpga_INTEGRATOR_ADC90_pin<1> LOC=3Dc5; NET fpga_INTEGRATOR_ADC90_pin<2> LOC=3Dc6; NET fpga_INTEGRATOR_ADC90_pin<3> LOC=3Dc7; NET fpga_INTEGRATOR_ADC90_pin<4> LOC=3Dc8; NET fpga_INTEGRATOR_ADC90_pin<5> LOC=3Dc9; NET fpga_INTEGRATOR_ADC90_pin<6> LOC=3Da3; NET fpga_INTEGRATOR_ADC90_pin<7> LOC=3Da4; NET fpga_INTEGRATOR_ADC180_pin<0> LOC=3Dc10; NET fpga_INTEGRATOR_ADC180_pin<1> LOC=3Dd11; NET fpga_INTEGRATOR_ADC180_pin<2> LOC=3Da13; NET fpga_INTEGRATOR_ADC180_pin<3> LOC=3Da12; NET fpga_INTEGRATOR_ADC180_pin<4> LOC=3Db11; NET fpga_INTEGRATOR_ADC180_pin<5> LOC=3Db10; NET fpga_INTEGRATOR_ADC180_pin<6> LOC=3Da8; NET fpga_INTEGRATOR_ADC180_pin<7> LOC=3Da7; NET fpga_INTEGRATOR_ADC270_pin<0> LOC=3Dd5; NET fpga_INTEGRATOR_ADC270_pin<1> LOC=3Dd6; NET fpga_INTEGRATOR_ADC270_pin<2> LOC=3De7; NET fpga_INTEGRATOR_ADC270_pin<3> LOC=3Dd7; NET fpga_INTEGRATOR_ADC270_pin<4> LOC=3Dd8; NET fpga_INTEGRATOR_ADC270_pin<5> LOC=3Dd10; NET fpga_INTEGRATOR_ADC270_pin<6> LOC=3Db4; NET fpga_INTEGRATOR_ADC270_pin<7> LOC=3Db5;Article: 104221
Jon Beniston wrote: > eascheiber@yahoo.com wrote: > > Hi all, > > > > I am using PowerPC on Virtex II Pro. The whole program is bigger than > > the cache, > > I suspect though that most of the times only a portion of the code is > > used that would > > fit into the cache. Is there a way I could ensure that this part of my > > code is so compiled > > that it could be all loaded into the cache at a time? I welcome any > > sugestions. > > The cache should work this out for itself. No need for you to tell it. > > Cheers, > Jon Unless ofcourse his code cycles through perverse data structures say 17 blocks, always defeating the cache associativity design. If the code is such that performance is consistant for varying scenarios, it has probably worked out okay, but if throughput drops for some patterns, look for thrashing. So it doesn't hurt to know the caches associative model to anticipate that. John JaksonArticle: 104222
If you are using gcc then have a look at -fprofile-arcs and -ftest-coverage command line options, they might help you out Hans www.ht-lab.com <eascheiber@yahoo.com> wrote in message news:1150896484.625259.61590@u72g2000cwu.googlegroups.com... > Hi all, > > I am using PowerPC on Virtex II Pro. The whole program is bigger than > the cache, > I suspect though that most of the times only a portion of the code is > used that would > fit into the cache. Is there a way I could ensure that this part of my > code is so compiled > that it could be all loaded into the cache at a time? I welcome any > sugestions. > > Regards, > e. >Article: 104223
Hi, I am looking for an FPGA development board that can host a Xilinx Virtex-4 XC4VSX25 device, because it has 128 multipliers and is supported by the free Xilinx ISE Webpack edition - however, much Googling has not turned up a board with this device. Can anyone tell me if a development board that hosts the Xilinx 'SX25 exists? - ideally this would have a PCI/PCI-X/PCI-E interface, but USB etc might be OK also. ThanksArticle: 104224
backhus, That is something that we thought about. But, really what we talking about is providing access to the crypto-engine through the general interconnect, and control of that engine. It was considered that anything we do in this regard would have to be completely and thoroughly tested so as not to be a back door, and compromise security. It wasn't worth the work to have to prove we did not break something. Even the JTAG is considered a real threat to security, so we have a method of disabling it once you have been configured with your encrypted bitstream (in V4 and V5). Kevin of FPGA Journal is looking for student interns for some security fun (in FPGAs). If anyone is interested, email me directly. We submitted our V2 Pro to 9 schools and universities (and some non-existent agencies) three years ago, and no one has broken the security, or even compromised it. That is what our security is about: we gave the students the complete schematics of the PCB, provided series access for PDA attacks, etc. All we asked was: tell us the key, or make the TRNG deliver non-random numbers (affect operation). We wqnt to know every weakness so we can fix it in the next version (and hopefully not break anything). Austin backhus wrote: > Hi Austin, > besides everything concerning the security gain of an encrypted > bitstream I have a different question. > > Xilinx offers a similar feature too in its Virtex4 (and 5?) FPGAs. > Now, that some silicon already is used up by the AES algorithm, wouldn't > it be nice to make it accessible to the custumer? Just the Keyscheduler > and the round function, not the key memory. > > Would be a nice feature for some custumers, but (nearly) no drawback for > all others. > > Best regards > Eilert
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