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
8 clock trees implemented because you could often use 9. Many thanks to Xilinx for not implementing 16 trees or Murphy would dictate 17 and any number > 1 is potential trouble.Article: 105451
Hi after some while MicroBlaze uClinux ready simulator is again available http://www.xilant.com/downloads/xsim_1_0.zip some screenshot is here http://xilant.com/content/view/44/2/ all ready to run, included are a few uclinux demo images (2.4.29 and 2.4.32) and also u-boot 1.1.14 MicroWindows tuxchess demo also included :) note that this is very prelim version - but several people have asked about the availabilty of the simulator so I made the early version available AnttiArticle: 105452
Thank everyone for replies. The info is helpful. There is one follow-up question for Austin. In Spartan-3 family, most hardware resource increases as the device becomes larger. If we compare 3S50 and 3S5000: - system gate: 50K vs 5M - block ram bit: 72K vs 1872K - multiplier: 4 vs 104 - user I/O: 124 vs 784 However, the number of clock tree remains the same (8) for all devices. Is there a reason for this? Thanks in advance. S. C. >Austin Lesea wrote: > S. C. > > One use I was given is that there is more than one design in the chip. > Sort of like an apartment building, with different tenants. > > Another use is for standard interfaces which you do not get to choose > the frequency: SDRAM at 266 MHz, PCI at 33 MHz, and a SONET core at 78 > MHz, all working together to perform some overall function. > > Austin > > >Article: 105453
PeteS, There is one thing you are missing: the package. You have no control over that. The value is less important. "A good match" is between 2:1. Really. Just run the simulations and you can see that happenening. Your tricks with the pcb are all lost because the package has a 1" long 50 ohm trace in it, with a capacitive load at its end (the transistors in their off state - not driving). If only the pad to the die where directly mounted to the pcb. But that is not possible with the die we have today (with as many as 1700 pcb bumps, and perhaps more than 10,000 package bumps). Austin PeteS wrote: > Austin Lesea wrote: > >>All, >> >>Any external resistor, no how well implemented is ever as good as an >>internal termination. It has to do with the short stub to the resistor >>which is unavoidable being a source of reflections. > > > True in a literal sense, provided one can get the precision, which is > not that easy in a standard IC. > That said, the parasitics you refer to are not an issue for an 0402 > device at 5Gb/s signalling (far higher speeds than the OP desires to > deal with in this case) - any such parasitics are swamped by other > issues of moving a signal across ciruit board (depends on the specific > circuit board, of course, but in this case I expect the project to be > FR-4 based). > > There are methods of dealing with the 'stub' (by necking the track to > the pad and trickery with adjacent grounds on the same layer) which > reduce it to the realm of effectively non-existent. > > For this particular case, if you look at the part I suggested, the only > discontinuity would be at the ball itself, and that is a minor issue. > > Cheers > > PeteS > > > >>That aside, the DCI for SSTL/HSTL is a resistance to ground from the >>rails, so it uses power (more than 200 IO's and we are talking some >>serious number of watts). >> >>Have you considered using LVCMOS DCI in a bidirectional mode? >> >>If you would like to see a signal integrity program result, email me >>directly (or request one from the hotline). >> >>Talking about it won't solve your problem. You have to do some real SI >>engineering for any custom IO requirement. In my opintion, it should be >>done for any IO requirement. >> >>Austin >> >>Austin >> >>PeteS wrote: >> >> >>>John Adair wrote: >>> >>> >>>>Your biggest issue is not the top surface area for the resistor site >>>>but the via space and extra routing needed to connect resistors. The >>>>vias especially will have significant routing effects. Even using a >>>>microvia blocks the path for potentially an extra signal. Conventional >>>>vias block 2 traces worth in our standard technology. BGA resistor >>>>packs whilst small tend not to have a good run of routing them and >>>>generally increase layer count to achieve the end result. >>>> >>>>John Adair >>>>Enterpoint Ltd. >>> >>> >>>Depends on what is being routed, of course. >>> >>>In this particular application, the signal can go in and out very >>>easily (1 track between balls for each ball position) and no vias at >>>all are required. >>> >>>In a parallel termination case, things are different, but for a series >>>terminator, the devices I have used work just fine with no extra layer >>>count required. Indeed, the part manufacturers are aware of the issue >>>that saving space for the package but providing poor access negates any >>>advantage of the package size, so parts are appearing that have decent >>>routing ability. >>> >>>Cheers >>> >>>PeteS >>> >>> >>> >>> >>>>PeteS wrote: >>>> >>>> >>>>>John Adair wrote: >>>>> >>>>> >>>>>>Standards like SSTL are good for this due to the low signal swing. The >>>>>>biggest decision is if to use DCI which burns more power in the V4 or to use >>>>>>external resistors which take board area and make routing more difficult. >>>>>> >>>>>>The other decision is weither you use source synchronous clocking or a >>>>>>common clock approach. At 150 Mhz the common clock is slightly marginal >>>>>>depending on how long tracks are, speed grade, etc. unless you use some DCM >>>>>>based techniques. You can generate a clock that is offset from the common >>>>>>clock a little by using a DCM and use that as clock for register input to >>>>>>gain more time. Alternatively you can use a DCM to null out the clock to >>>>>>output time and get more margin from that. >>>>>> >>>>>>John Adair >>>>>>Enterpoint Ltd. - Home of Broaddown4. The Ultimate Virtex-4 Development >>>>>>Board. >>>>>>http://www.enterpoint.co.uk >>>>>> >>>>>> >>>>>>"Marc Reinig" <Marco@newsgroups.nospam> wrote in message >>>>>>news:44bc1fed@darkstar... >>>>>> >>>>>> >>>>>>>I have a project where I will have a large array of V4 FPGAs. Each chip is >>>>>>>intended to connect to its four orthogonal neighbors with no intervening >>>>>>>logic. I would like the number of bus connections between chips in any >>>>>>>direction in the array to be 150 (600 total I/O per chip). The connections >>>>>>>will be bi-directional. The distance between chips will be the minimum I >>>>>>>can have with sockets, heat sinks (with individual fans), good layout and >>>>>>>noise control. Some of the lines, what ever is necessary, will be used for >>>>>>>clock and framing for the bus data signals. I would like to use DDR. >>>>>>>During bus transfers, all the lines on opposite sides of the chip will be >>>>>>>operating and the other two sides will be quiescent. I'm hoping for a bus >>>>>>>clock of 150 MHz. >>>>>>> >>>>>>> >>>>>>>Comments? ;=) >>>>>>> >>>>>>>Marco >>>>>>>________________________ >>>>>>>Marc Reinig >>>>>>>UCO/Lick Observatory >>>>>>>Laboratory for Adaptive Optics >>>>>>> >>>>>>> >>>>> >>>>>If Marc uses SSTL, and uses resistive terminators, I would agree it >>>>>takes board space, but I disagree it would make routing significantly >>>>>more difficult, except for the sheer number of devices. In a point to >>>>>point situation only a series terminator is really required for speeds >>>>>up to at least 200MHz / 400Mb/s (I've done it). >>>>> >>>>>Assuming these busses would be bidirectional, external series resistors >>>>>would [arguably, at least] actually be better in reducing EMI and >>>>>reflections than just DCI (less power too) assuming the devices are >>>>>close together (of the order of perhaps 4 inches or less). Much really >>>>>depends on the distance. I've used BGA style resistor packs that cram >>>>>more resistors into the device than can be done in multipack type SMT >>>>>devices. Apart from that, the tiny quad pack devices are particularly >>>>>sensitive to even slightly imperfect chip shooters and have a nasty >>>>>tendency to crack the resistor, particularly at the ends of the device. >>>>> >>>>>CTS corp makes a particularly nice range of devices >>>>>(http://www.ctscorp.com/components/clearone.asp) [I have no affiliation >>>>>with them except for having used the parts in the past]. >>>>> >>>>>Cheers >>>>> >>>>>PeteS >>> >>> >Article: 105454
Hello all, Fairly new user to Xilinx microblaze here (and first post to this user group). I'm trying to write C-code (within Xilinx Platform Studio) to determine the remainder after an integer division. So if I say num = 13/10; rem = 13%10; then num = 1 and rem = 3. I'm getting an error stating "invalid operands to binary %" when I try to build. What I surmise is that % is trying to convert to a binary format rather than obtaining the desired remainder result. I would also assume that I need to include the correct header file in order to perform the remainder operation. However, I'm having trouble determining what math functions are available w/in microblaze and the associated symbols needed to perform desired functions (i.e., how to determine an integer remainder). When I'm configuring microblaze in fpga hardware, should I use floating point? I can't find any math include file under <design>/microblaze_0/include. Thanks for the help in figuring this out. I'm sure there's an easy answer...Article: 105455
Yes, It is called "simplicity." If the clock tree were to vary, it would make the assembly of each family member part even more of a hassle (than it already is), and the software would also have to be "different" for each member of the fanily (more than it already is). Thus, to make the resource the same for the smallest or largest part may be seen as a waste, yet it is the only practical way to manufacture a family of devices, and support them. The same is true for the routing resources: a small part does not "need" all we provide, and a "large" part has perhaps too little (for some designs). Austin fp wrote: > Thank everyone for replies. The info is helpful. > > There is one follow-up question for Austin. In Spartan-3 family, most > hardware resource increases as the device becomes larger. If we > compare 3S50 and 3S5000: > - system gate: 50K vs 5M > - block ram bit: 72K vs 1872K > - multiplier: 4 vs 104 > - user I/O: 124 vs 784 > > However, the number of clock tree remains the same (8) for all devices. > Is there a reason for this? > > Thanks in advance. > > S. C. > > > >>Austin Lesea wrote: >>S. C. >> >>One use I was given is that there is more than one design in the chip. >>Sort of like an apartment building, with different tenants. >> >>Another use is for standard interfaces which you do not get to choose >>the frequency: SDRAM at 266 MHz, PCI at 33 MHz, and a SONET core at 78 >>MHz, all working together to perform some overall function. >> >>Austin >> >> >Article: 105456
While looking for a circuit for an Altera ByteBlasterMV, I found this one for an original BB: <http://opencollector.org/history/freecore/Build%20your%20own%20ByteBlaster!.htm> The MV uses a 74HC244 instead of the LS one, and that means that the unused inputs need to be pulled high. But with the '244 running at 3.3v, for example, won't the parallel port cause latchup by pulling the inputs too high? Is it ok to connect the inputs using series resisters to avoid that? What value should I use? Any other changes needed to make this work at 3v3 with an EPM3064? Clifford Heath.Article: 105457
Davy wrote: > Hi all, > > Is there some hardware RTL book like "Code Complete" by Steve > McConnell? > Unlikely. Creating software is far less complex and variable than creating hardware. IanArticle: 105458
I have a 256x8 bit look up table in my vhdl design and I reach this look up table 64 times. I am using Synplify 8.6.1 to synthesize my code for ACTEL Ax or Proasic family and tool infers a lot of ROMs for this table. As soon as I understand this inferred ROMs are made up of logic gates not reserved block Rams in the technology. I heard that there is an attribute for Xilinx Virtex family named "select_ROM" in order to use block Rams instead of wasting logic gates of resources. Is there any attribute for Actel family? I would appreciate your help.Article: 105459
I am afraid, the only way to find out, is to partly delete files and try to reconstruct in order fo find out, what can be thrown away and what should be kept.Article: 105460
Hi, try the following: signal ls_rom_out : std_logic_vector(... downto 0); attribute syn_romstyle : string; attribute syn_romstyle of ls_rom_out : signal is "select_rom"; I do not know whether it can be applied with Actel devices ... Rgds Andr=E9Article: 105461
manu wrote: > Hello, > for the moment, I use SVN to manage different versions of te VHDL code > of my projects. > I'd like to manage my xilinx projects based on my VHDL code too. > Until now, I just put the <project>.ise and <project>.ucf files under > version control and it was enough to be rebuild the whole project. > Now, I've added an embedded processor to my ISE design and I'm a bit > confused because there a huge set of automatically generated files. I'd > like to keep under version control just the minimum set of files > required to rebuild the whole project. I think there's at least the > <project_up>.xmp, <project_up>.mhs and <project_up>.mss files, but is it > enough ? Theoretically, those should be enough, plus your pcores-directory (in case you have created your own peripherals) and the directory where you store your application code (the C-code for your program). Putting anything else in the repository will not work smoothly, because EDK deletes whole directory trees when you clean up the project to have it synthesize again. The implementation directory for example... usually I would like to check in the created netlist files, but once you re-run the EDK flow, EDK deletes the directory including the hidden CVS directories, so your usual CVS client gets really confused... cu, SeanArticle: 105462
I try to use the opb/iba unit of chipscope to monitor the opb bus within a simple edk design. I took the chipscope lab example as start point. I am able to see the OPB signals in chipscope, but I can not set a trigger point. For example, I want to trigger at a certain address 0xFFFFXXXX. If I wait for the triggercondition, the behaviour is the same if no condition is set (like the immediate trigger button is clicked). Another problem is: I don't see assembly or c-source code in the listing window. Do I have to tell chipscope where it can find sources? What could be wrong? In the lab example there are three control ports instantiated at the ICON unit while only two ports are connected. I have two control ports instantiated and connected, because ISE failed at the unconnected control port (in the map phase). Any ideas? FrankArticle: 105463
"gollum" <etoktas@gmail.com> wrote in message news:1153725459.998815.222190@i42g2000cwa.googlegroups.com... >I have a 256x8 bit look up table in my vhdl design and I reach this > look up table 64 times. > > I am using Synplify 8.6.1 to synthesize my code for ACTEL Ax or Proasic > family and tool infers a lot of ROMs for this table. > > As soon as I understand this inferred ROMs are made up of logic gates > not reserved block Rams in the technology. > > I heard that there is an attribute for Xilinx Virtex family named > "select_ROM" in order to use block Rams instead of wasting logic gates > of resources. If you're using VHDL you might consider using LPM_ROM instead of however it is you've coded your table in the code. LPM is a standardized set of functions (Library of Parameterizable Modules...or something like that) that will make your code portable and totally avoid use of vendor specific attributes. KJArticle: 105464
Clifford Heath wrote: > While looking for a circuit for an Altera ByteBlasterMV, > I found this one for an original BB: > <http://opencollector.org/history/freecore/Build%20your%20own%20ByteBlaster!.htm> > > The MV uses a 74HC244 instead of the LS one, and that means > that the unused inputs need to be pulled high. But with the > '244 running at 3.3v, for example, won't the parallel port > cause latchup by pulling the inputs too high? Is it ok to > connect the inputs using series resisters to avoid that? > What value should I use? > > Any other changes needed to make this work at 3v3 with an > EPM3064? I've designed a similar unit using a 74HC244. In theory, there could be a problem, but mine works fine with 3.3V devices. I've sold a few of them, as well. I think that a 74AC244 might be better. LeonArticle: 105465
"fp" <fpga002006@yahoo.com> writes: > Synchronous design, in which all FFs are synchronized by a single > clock, perhaps is the single most important methodology. In a Xilinx > Spartan-3 FPGA, there are 8 clock trees, even for the smallest device. > What is the purpose of these clocks? > - Could someone provide me few meaningful examples (not sloppy design) > that use multiple clocks? How about one of our image processing designs: 3x async camera inputs (yes, it would be great to have synchronous cameras, but it doesn't happen) @ 30MHz 1x DSP memory-mapped IO interface @ 100MHz 1x VGA frame-buffer @ 100MHz - synchronous to the DSP clock - yay! 1x VGA output @ (800x600x75)=36MHz I had to move the cameras into the DSP clock domain, process data, pass on to the DSP for further processing, then get "pixels to plot" back from the DSP to put into the VGA frame-buffer. This data was then streamed out through a FIFO to the VGA RAMDAC. I don't think I could have got away with less domains, but with careful planning of the interfaces, it all worked. Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.trw.com/conektArticle: 105466
KJ wrote: > "Tommy Thorn" <tommy.thorn@gmail.com> wrote in message > news:1153510009.206861.78040@p79g2000cwp.googlegroups.com... > > Andy wrote: > >> Too bad the author is a proponent of the ancient style of separate > >> clocked and combinatorial processes in VHDL. He even uses a third > >> process for registered outputs. > >> > >> I think he needs to discover what variables can do for you in a clocked > >> process. > > > > Really? Which of his arguments do you disagree with? > > > > I always thought of the two-process style as being redundant, but after > > reading Dr. Chu's argument, I'm revising my thinking. For one thing, > > this style makes it much less disruptive to change a Moore output to a > > Mealy and vise versa. > > > > My thanks to S.C. for the reference. Good one. > > > > But in practice one doesn't much care if any outputs are 'Mealy' or 'Moore'. > What one has is a function that needs to be implemented within specific area > (or logic resource) constraints and performance (i.e. clock cycle, Tpd, Tsu, > Tco) constraints. > > Breaking what can be accomplished in one process into two (or more) > logically equivalent processes should be considered for code clarity which > can aid in support and maintenance of the code during it's lifetime as well > as for potential design reuse (although realistically re-use of any single > process is probably pretty low). Re-use happens more often at the > entity/architecture level, but the 'copy/paste/modify' type of re-use > probably happens more at the process level when it does happen. > > Breaking a process into two just to have a combinatorial process to describe > the 'next' state and a separate process to clock that 'next' state into the > 'current' state has no particular value when using design support and > maintenance cost as a metric of 'value'. Since the different methods > produce the final end logic there is no function or performance advantage to > either approach. On the other hand, there are definite drawbacks to > implementing combinatorial logic in a VHDL process. Two of these are > - Introduction of 'unintended' latches > - Missing signals in the sensitivity list that result in different > simulation versus synthesis results > > Both of these drawbacks have manual methods that can be used to try to > minimize them from happening but the bottom line is that extra effort > (a.k.a.. cost or negative value) must be incurred to do this....all of which > is avoided by simply not using the VHDL process to implement combinatorial > logic (i.e. the 'next' state computation). > > So as far as the VHDL language is concerned, there are real costs that will > be incurred every time the two process method is used but no real value > add....or at least that's my 2 cents..... > > KJ After reading the arguments here, I have started using a mixed approach, but I still use the two process model for state machines and other complex logic. There are just too many times when I don't want to wait until the next clock for an output to take affect. At work, we have a hard requirement (as in, it won't pass a peer review) to write in the two process model. Another hard requirement (that I agree with) is that there should only be one clocked process per clock. The guy that came up with the requirement predates HDL's in general - and I'm sure there was a good reason for it at one time. However, for my home projects, I tend to mix the one and two-process models based on what is most convenient. Having done so, I don't see that the two-process model is that terribly inconvenient. I simply place a default condition at the beginning of the process, and override the default as needed. For most processes, this adds maybe 1-10 "extra" lines. Perhaps it's because I was taught in the two-process model, but I find it easier to understand what is going on when I use it, so anything that requires me to think, I use a separate combinatorial process for. Simple logic, like counters, pipeline registers, etc. goes into the appropriate clocked process. For me, this mixed approach works pretty well.Article: 105467
Thanks for your time, Austin. Now I see why 3C50 has 8 clock trees. S. C. Austin Lesea wrote: > Yes, > > It is called "simplicity." > > If the clock tree were to vary, it would make the assembly of each > family member part even more of a hassle (than it already is), and the > software would also have to be "different" for each member of the fanily > (more than it already is). > > Thus, to make the resource the same for the smallest or largest part may > be seen as a waste, yet it is the only practical way to manufacture a > family of devices, and support them. > > The same is true for the routing resources: a small part does not > "need" all we provide, and a "large" part has perhaps too little (for > some designs). > > Austin > > fp wrote: > > > Thank everyone for replies. The info is helpful. > > > > There is one follow-up question for Austin. In Spartan-3 family, most > > hardware resource increases as the device becomes larger. If we > > compare 3S50 and 3S5000: > > - system gate: 50K vs 5M > > - block ram bit: 72K vs 1872K > > - multiplier: 4 vs 104 > > - user I/O: 124 vs 784 > > > > However, the number of clock tree remains the same (8) for all devices. > > Is there a reason for this? > > > > Thanks in advance. > > > > S. C. > > > > > > > >>Austin Lesea wrote: > >>S. C. > >> > >>One use I was given is that there is more than one design in the chip. > >>Sort of like an apartment building, with different tenants. > >> > >>Another use is for standard interfaces which you do not get to choose > >>the frequency: SDRAM at 266 MHz, PCI at 33 MHz, and a SONET core at 78 > >>MHz, all working together to perform some overall function. > >> > >>Austin > >> > >> > >Article: 105468
radarman wrote: > > After reading the arguments here, <snip> There are just too many times > when I don't want to wait until the next clock for an output to take affect. Stop being so impatient ;) > Another hard requirement > (that I agree with) is that there should only be one clocked process > per clock. The guy that came up with the requirement predates HDL's in > general - and I'm sure there was a good reason for it at one time. > This struck me as kind of odd. I understand that if there is a hard requirement to do it this way then you either will do it that way or seek other employment. I also don't find it hard to believe either that the reason for the requirement for may predate HDLs and there was a good reason for it at one time. What I find odd though is that you agree with it. Based on your other posts to this group I could see that you could 'accept' that this is how you have to do it but I guess I'm surprised that you would 'agree with' something that you don't know what the reasoning is...doesn't seem like 'radarman' talking. By the way, if you do find the 'good' reason for having physically only one clocked process I'd be curious to hear what it is. Although I put myself in the 'one process' camp my 'one process' tends to be several physical processes all clocked by the same clock. From a logic synthesis/simulation perspective those multiple processes are all logically 'one' process but breaking them up into physically separate processes I find makes it easier to understand and debug. KJArticle: 105469
Ditto I am looking at using 4 of the fpu cores provided with ISE and writing the instruction decode and glue logic myself. This seems like a generic enough problem that there must be an easier way. I have been having the same problems -mhard-float does not make GCC target an FPU and the documentation on the APU is slim. Let me know if you hear anything/ have a great breakthrough, ill do the same.Article: 105470
EEngineer wrote: > What is the ACE file size that you created? All the demos are 1686KB > and the new ACE created with iMPACT is 1674KB. The file that I generated was 1686KB using the 8.1.03i (Service Pack 3) software. You can find out which version you are using the "Help -> About" menu. EdArticle: 105471
Mike Treseler wrote: > Eric wrote: > > >>But if anyone writes a book like this it will fly off the shelves! > > > A few hundred copies would fly off the shelves. > > There's probably about 10,000 digital designers > in the US. Not all of those do hardware description > and not all of those write their own RTL. > Those are not numbers that would excite > a major publisher. It can't justify the cost and delay of hard-copy but could easily be sold as a pdf. Forget the idea of publishing a single work. This should be a work in progress that is always adding new chapters and ideals and evolving with the industry. > Writing and editing a book is two long years > of work, whatever the subject. > > -- Mike Treseler Two long man years. Quadruple that if you have multiple authors that need to coordinate their works and then divide by the number of authors on the project. Many hands make light work. Get a couple of dozen of experienced designers, a bunch of proof reading fact checkers and one decent editor and you got yourself an open source book writing project. Put it out on sourceforge for free and make it useful for any digital designer at any stage in their career or hobby.Do a really good job and it can become the "bible" of the industry that everyone has in the library. Do we have the critical mass to pull something like this off? Lets do a survey. If we did a cooperative book on digital design guidelines then what chapters would you like to see and or contribute. my list: 1) Reset systems and how they work. 2) Designing logic for scan testing (atpg) 3) Designing bist test logic 4) Designing and using jtag test logic 5) Designing and using in-chip diagnostic and debugging logic John EatonArticle: 105472
> group). I'm trying to write C-code (within Xilinx Platform Studio) to > determine the remainder after an integer division. So if I say > > num = 13/10; > rem = 13%10; > > then num = 1 and rem = 3. > > I'm getting an error stating "invalid operands to binary %" when I try > to build. You might want to check if your code compiles fine on an Intel machine. '%' as an operation only makes sense for integers. > > What I surmise is that % is trying to convert to a binary format rather > than obtaining the desired remainder result. I would also assume that > I need to include the correct header file in order to perform the > remainder operation. If num & rem are int's, then you don't need any headers. > > However, I'm having trouble determining what math functions are > available w/in microblaze and the associated symbols needed to perform > desired functions (i.e., how to determine an integer remainder). > > When I'm configuring microblaze in fpga hardware, should I use floating > point? I can't find any math include file under > <design>/microblaze_0/include. > That depends on whether you need the hardware FPU or not. The GNU includes are typically in $XILINX_EDK/gnu /SArticle: 105473
Check your trigger conditions. In the trigger window, apart from specifying the value for each trigger, you also have to mention exactly which trigger condition (or a boolean combination of conditions) needs to be enabled. /S Frank van Eijkelenburg wrote: > I try to use the opb/iba unit of chipscope to monitor the opb bus within > a simple edk design. I took the chipscope lab example as start point. I > am able to see the OPB signals in chipscope, but I can not set a trigger > point. For example, I want to trigger at a certain address 0xFFFFXXXX. > If I wait for the triggercondition, the behaviour is the same if no > condition is set (like the immediate trigger button is clicked). Another > problem is: I don't see assembly or c-source code in the listing window. > Do I have to tell chipscope where it can find sources? What could be wrong? > > In the lab example there are three control ports instantiated at the > ICON unit while only two ports are connected. I have two control ports > instantiated and connected, because ISE failed at the unconnected > control port (in the map phase). > > Any ideas? > FrankArticle: 105474
Hey all, Thanx in advance for any help. I've got a few FIFO cores that I created in Xilinx Core Generator. I instantiated them in my top level VHDL, and added the syplicity blackbox declarations after the component declarations, as specified in the various Xilinx/Synplicity documents: -- Synplicity black box declaration attribute syn_black_box : boolean; attribute syn_black_box of serial_fifo : component is true; I added the top level vhdl, and the Xilinx generated EDIF netlists to my synplicity project... when I run it I get: warning ID MT246 : Blackbox output_fifo_fifo_generator_v2_3_xst_1 is missing a user supplied timing model. Now, from everything I read in the various PRF documents, the purpose of adding the EDIF files to the synplicity project is to generate said timing? No? Anyone know why synplicity is complaining here? Thanx.
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