Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
I am using Release Version: 8.1i Application Version: I.24 I always get 1674KB ACE file, maybe that points to some problem? Ed McGettigan wrote: > 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: 105476
I use: Service Pack 1 Ed McGettigan wrote: > 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: 105477
Summary of Bitgen Options: +----------------------+----------------------+ | Option Name | Current Setting | +----------------------+----------------------+ | Compress | (Not Specified)* | +----------------------+----------------------+ | Readback | (Not Specified)* | +----------------------+----------------------+ | CRC | Enable** | +----------------------+----------------------+ | DebugBitstream | No** | +----------------------+----------------------+ | ConfigRate | 4** | +----------------------+----------------------+ | StartupClk | JtagClk | +----------------------+----------------------+ | CclkPin | Pullup** | +----------------------+----------------------+ | DonePin | Pullup** | +----------------------+----------------------+ | HswapenPin | Pullup* | +----------------------+----------------------+ | M0Pin | Pullup** | +----------------------+----------------------+ | M1Pin | Pullup** | +----------------------+----------------------+ | M2Pin | Pullup** | +----------------------+----------------------+ | PowerdownPin | Pullup* | +----------------------+----------------------+ | ProgPin | Pullup** | +----------------------+----------------------+ | InitPin | Pullup** | +----------------------+----------------------+ | CsPin | Pullup** | +----------------------+----------------------+ | DinPin | Pullup** | +----------------------+----------------------+ | BusyPin | Pullup** | +----------------------+----------------------+ | RdWrPin | Pullup** | +----------------------+----------------------+ | TckPin | Pullup** | +----------------------+----------------------+ | TdiPin | Pullup** | +----------------------+----------------------+ | TdoPin | Pullup** | +----------------------+----------------------+ | TmsPin | Pullup** | +----------------------+----------------------+ | UnusedPin | Pulldown** | +----------------------+----------------------+ | GWE_cycle | 6** | +----------------------+----------------------+ | GTS_cycle | 5** | +----------------------+----------------------+ | LCK_cycle | NoWait** | +----------------------+----------------------+ | Match_cycle | Auto* | +----------------------+----------------------+ | DONE_cycle | 4** | +----------------------+----------------------+ | Persist | No* | +----------------------+----------------------+ | DriveDone | No** | +----------------------+----------------------+ | DonePipe | No** | +----------------------+----------------------+ | Security | None** | +----------------------+----------------------+ | UserID | 0xFFFFFFFF** | +----------------------+----------------------+ | ActivateGclk | No* | +----------------------+----------------------+ | ActiveReconfig | No* | +----------------------+----------------------+ | PartialMask0 | (Not Specified)* | +----------------------+----------------------+ | PartialMask1 | (Not Specified)* | +----------------------+----------------------+ | PartialMask2 | (Not Specified)* | +----------------------+----------------------+ | PartialGclk | (Not Specified)* | +----------------------+----------------------+ | PartialLeft | (Not Specified)* | +----------------------+----------------------+ | PartialRight | (Not Specified)* | +----------------------+----------------------+ | Encrypt | No** | +----------------------+----------------------+ | Key0 | pick* | +----------------------+----------------------+ | KeyFile | (Not Specified)* | +----------------------+----------------------+ | StartCBC | pick* | +----------------------+----------------------+ | DCIUpdateMode | AsRequired** | +----------------------+----------------------+ | ICAP_Select | Auto* | +----------------------+----------------------+ | IEEE1532 | No* | +----------------------+----------------------+ | Binary | Yes | +----------------------+----------------------+ * Default setting. ** The specified setting matches the default setting. Running DRC. DRC detected 0 errors and 0 warnings. Creating bit map... Saving bit stream in "test.bit". Saving bit stream in "test.bin". Bitstream generation is complete.Article: 105478
With variables, you don't have to wait an extra clock in single process descriptions. Andy radarman wrote: > 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: 105479
> My impression is that hardware people don't like to write much, and > even if they do, they don't have time to sit down and document all of > the important "big issues" that new people need to learn in order to be > effective. > > But if anyone writes a book like this it will fly off the shelves! Care to estimate the size of the market? I.e. how much would the author expect to make, given typical publishing contracts? (I've long wanted to write such a book, but have trouble with the business case - i.e. persuading my wife. And, of course, I cannot write it as an employee of Intel.)Article: 105480
> > 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. I've been bitten in the hindquarters with cross-clock domain problems too many times. I now have one clocked process per clock. While I try to avoid cross-clock asynchronous resets, occasionally (especially in CPLD's) there is no other choice. I find that by doing this, I catch clock domain crossing errors more easily. For example. On one design, I had a bus interface running on a fixed clock (32MHz), internal logic on another fixed clock (40MHz), a state machine that controlled a digital synthesizer (DDS 9858) that ran on the DDS utility clock (40MHz, but asynchronous to the previous clock), and a whole other section of code that ran on the clock generated by the synthesizer (approximately 40MHz, but variable within a band). To summarize: Local bus clock -> 32MHz. Local bus I/F and control -> 40MHz (fixed) DDS controller -> 40MHz (frequency locked, but not phase locked to the previous) "special logic" -> 38MHz < f < 42MHz from DDS. Now, in most cases I was able to limit the crossings. There were a few F40 <-> V40 crossings due to the nature of the design, but I tried to restrict those to a handful of sentinel signals with strict timing, and used rate-change FIFO's where timing wasn't critical. To simplify things a bit, I created two copies of the bus interface - one for the 40MHz fixed, and another for the 40MHz variable. However, in the actual DDS controller, I had all three clocks in play at once. My design had to be able to frequency and phase lock the DDS output frequency to the fixed 40 (which is quite doable, even if the design to do so "looks" terrible). To make things more fun, it had to issue the controls to the DDS aligned with the DDS utility clock - so the state machine ran on that clock domain. Thankfully, the DDS utility clock was reliably 90 degrees out of phase with the F40 domain, so I could design a proper clock boundary crossing circuit. The one time I fooled around with multiple clocked processes and multiple clock domains, I ended up spending days (weeks?) debugging a pernicious little problem that took hours of operation to fail. I accidentally clocked something that was in the fixed 40MHz domain with the variable 40MHz. It took a long time to debug that problem because the per-operation error was so small. Unfortunately, even though the error was only +/- a few nanoseconds worst case, it was cumulative, and would cause the system to fail eventually. While I would have been given leave to violate the design guidelines with that module, given the complexity of the clock domain crossings, I found it was better to follow them. Eventually, it dawned on me that a certain register was in the wrong process. By putting all of the registers for each domain in a single process, I was able to wrap my head around the problem more easily. As a result of that experience, I also started adding the clock domain as a suffix to the signal name in complex designs. It leads to long names, but it is worth the effort.Article: 105481
Hello All, I am having a hard time understanding EDK ---> FPGA tool flow (I think). I am using EDK/ISE 8.1, testing the Generic Reference Design from Memec/Avnet. It is for the Xilinx FX12 mini-module. I have been able to use the drivers supplied to control the LCD screen, rs232 uart and the user LEDs as expected. But when it comes to a specific FPGA pin of my choice I'm getting lost. I first started out with their example, and created my own spin off of theirs, trying to learn my way around the IDE of EDK. All is working well except my understanding of the UCF file corresponding to the data inside EDK. Ok, so in my xparameters.h file I see there are refferencing the memory locations for each component in the system assembly. So in C I can assign these "registers" via the drivers and get expected results. When it comes down to bit by bit I am lost. Is the UCF file that I'm using generated by EDK, or did someone from memec hand sculpt this? Maybe I have to import this into an ISE project to get the big picture? When I assign a gpio output 0x0550 I can see one 5 on my FPGA pins, but not in the order I would expect it. Really it's not a five at all, unless I'm reading all the even pins. And I thought the gpio output was 32 bit, so why in the UCF file is there only 10 pins assigned to the gpio output port(s)? I hope I am not being to vague/mis-guided, and even confusing you guys. Because I have certianly exhausted my confusion. I've also read over a ton of documentation from XIlinx, about EDK, the drivers, etc... I was searching for that golden document that would tell me exactly what I needed to know and I havn't found it yet. Maybe I am not looking for the correct topics in the manuals? Maybe I need to read over PowerPC user guide a bit more? Help point me in the wright direction! Thanks, KyleArticle: 105482
KJ wrote:
> 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.
No signal declarations or direction
conflicts to worry about.
Output register variable values
are assigned directly to out ports.
-- Mike Treseler
Article: 105483
Andy Glew wrote:
> Care to estimate the size of the market?
2000-4000 copies over 2 years.
>
> I.e. how much would the author expect to make, given typical publishing contracts?
Maybe $4 per book.
> (I've long wanted to write such a book, but have trouble with the
> business case
There isn't one.
You would have to do it for love, not money.
> And, of course, I cannot
> write it as an employee of Intel.
I expect that would be negotiable.
RTL design is hardly proprietary.
-- Mike Treseler
Article: 105484Do Actel Block RAMs require registered reads (one clock delay from addr to data)? That may be your problem if your RTL does not mimic that behavior. Andy gollum wrote: > 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: 105485
At least one. I'd buy it. ;-). Suggestion: Do it like the guy who wrote "Thinking in JAVA" did. As he finished a chapter, he posted it on his website for people to review. He got tons of corrections and feedback, which he then used to update the chapter. At the end of it all, he published a hardcopy and to his surprise found out he sold more than expected - because everyone who had read it online wanted a copy on his/her desk, and because it was online originally it was highly anticipated when it was actually published. Seems counter-intuitive, but I believe it would work for a tome such as this... (and if you did it right, you could generate a few bucks before it every gets published, wink-wink, nudge-nudge, hint-hint, know-what-I-mean--know-what-I-mean?). Regards, Dean "Andy Glew" <first.last@employer.domain> wrote in message news:peyp8xmjgc51.fsf@PXPL8591.amr.corp.intel.com... > > My impression is that hardware people don't like to write much, and > > even if they do, they don't have time to sit down and document all of > > the important "big issues" that new people need to learn in order to be > > effective. > > > > But if anyone writes a book like this it will fly off the shelves! > > Care to estimate the size of the market? > > I.e. how much would the author expect to make, given typical publishing contracts? > > (I've long wanted to write such a book, but have trouble with the > business case - i.e. persuading my wife. And, of course, I cannot > write it as an employee of Intel.)Article: 105486
[snip] I think what Dean means to say is that he knows an excellent, reputable website that would put something online and attract a lot of good readers : ) And if you do a good job, I bet you could persuade Intel to start buying up copies in bulk for NCGs. DKArticle: 105487
I see that Xilinx claim 0.92 Dhrystone 2.1 mips/Mhz for Microblaze and Altera varously up to 1.2 dmips/Mhz. Does anyone know if these are measured with inlining enabled? I found Xilinx XAPP507 which implies that their headline "DMIPS" figure for the embedded powerPCs is with inlining enabled but I can't find anything similar for the soft cores.Article: 105488
Mike Treseler wrote: > KJ wrote: > > > > 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. > > No signal declarations or direction > conflicts to worry about. You have variable declarations instead....not sure what 'direction conflicts' you're talking about but if it's multiple processes both 'outputting' some signal than not using 'resolved' logic types allows the compiler to catch that straight out also. > Output register variable values > are assigned directly to out ports. > And this is better (or just different) than output register signals values being assigned to out ports? KJArticle: 105489
radarman wrote: > Eventually, it dawned on me that a > certain register was in the wrong process. By putting all of the > registers for each domain in a single process, I was able to wrap my > head around the problem more easily. > > As a result of that experience, I also started adding the clock domain > as a suffix to the signal name in complex designs. It leads to long > names, but it is worth the effort. OK, good explanation, I wasn't immediately considering the entities with several clocks in them. I'd submit though that most of the real value was in the naming convention of adding the clock domain suffix to the signal name (which is something that I do as well by the way) and not so much that they were all physically in one process. If you agree that the naming convention was probably the more important of the two then from your description it appears that 'the company' didn't have signal naming rules in place....and that would've been a bigger help if it did. In other words, the clock domain suffix certainly would qualify as one of those 'good' patterns for all to follow and your problem description is a case for why. The jury is still out in my mind on the physically one clocked process requirement, to me it can lead to a lot of scrolling back and forth to make sure one understands all of the places where signals get assigned. But I'll also accept that in the multi-clock entities that one needs to be even more rigid than usual since the tools are of almost no help in helping to make sure you're crossing domains properly.....and dang, why is that anyway it's not like it brain surgery. KJArticle: 105490
On 2006-07-24, Clifford Heath <no@spam.please.net> wrote: > > The MV uses a 74HC244 instead of the LS one, and that means A LOT of target-powered parallel port programming dongles use the HC244 with 3V targets. I've used the Byteblaster you mentioned, as well as the Kanda AVR programmer (w/ 3V target). > '244 running at 3.3v, for example, won't the parallel port > cause latchup by pulling the inputs too high? If you look at a datasheet you'll see the input clamp current is 20mA, so you could work it out from that. In practice, though, most of those dongles use a diode between target VCC and power, so the target can't actually sink any current at 3V, so the 5V that gets through the protection diodes on the HC244 probably just raises its supply rail above the target voltage. So really it'd be the target that would see higher voltages. Anyway, I'd leave out the resistors. The last programming dongle I made used a 1k resistor for the return (between the buffer and the parallel port). Looked fine on a scope, didn't work. Shorted it out, worked fine. -- Ben Jackson AD7GD <ben@ben.com> http://www.ben.com/Article: 105491
> 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. > Certainly an interesting idea. > > Do we have the critical mass to pull something like this off? > Always a big question...the other important question is finding the 'leader' to prod this along to get it going in the first place. KJArticle: 105492
KJ wrote:
> You have variable declarations instead....not sure what 'direction
> conflicts' you're talking about but if it's multiple processes both
> 'outputting' some signal than not using 'resolved' logic types allows
> the compiler to catch that straight out also.
True. My point is that keeping track of signal
direction relative to each process is manual
bookkeeping that I don't have to with a single process.
>> Output register variable values
>> are assigned directly to out ports.
>>
> And this is better (or just different) than output register signals
> values being assigned to out ports?
Simpler because *all* of my registers are variables.
There is no need to interpose a signal. Just
my_out_port <= my_out_reg_v;
-- Mike Treseler
Article: 105493Hi, I am trying to implement a correlator block in a Virtex-4 FPGA. This FPGA is connected to an ADC08D1500 chip and the board is set up such that 4096 samples are collected and the 8-bit data is sent to the USB controller which in turn serializes it and sends it to the host PC. Initially I thought of going ahead with the bit correlator, but that's not what I want. I want a 2 input corrrelator that correlates the data. Let me know if anyone has a sample code or has experience working with National Semiconductor ADC08D1500 dev board. Thanks, VivekArticle: 105494
Andy wrote: > With variables, you don't have to wait an extra clock in single process > descriptions. > With concurrent signal assignments that are outside of the process you don't have to wait an extra clock either. KJArticle: 105495
EEngineer wrote: > I use: > > Service Pack 1 > I would definitely try upgrading to Service Pack 3. Ed McGettigan -- Xilinx Inc.Article: 105496
On 24 Jul 2006 10:12:42 -0700, Andy Glew <first.last@employer.domain> wrote: >> My impression is that hardware people don't like to write much, and >> even if they do, they don't have time to sit down and document all of >> the important "big issues" that new people need to learn in order to be >> effective. >> >> But if anyone writes a book like this it will fly off the shelves! > > Care to estimate the size of the market? I can't guess that. > I.e. how much would the author expect to make, given typical publishing contracts? > > (I've long wanted to write such a book, but have trouble with the > business case - i.e. persuading my wife. And, of course, I cannot > write it as an employee of Intel.) From the software world, I suggest that you take a look at Scott Meyers web site: http://www.aristeia.com/authorAdvice_frames.html A bientot Paul -- Paul Floyd http://paulf.free.fr (for what it's worth) Surgery: ennobled Gerald.Article: 105497
Mike Treseler wrote: > KJ wrote: > > > You have variable declarations instead....not sure what 'direction > > conflicts' you're talking about but if it's multiple processes both > > 'outputting' some signal than not using 'resolved' logic types allows > > the compiler to catch that straight out also. > > True. My point is that keeping track of signal > direction relative to each process is manual > bookkeeping that I don't have to with a single process. > But if you use an unresolved type you're not doing the bookkeeping either, the compiler is when it complains about multiple drivers on an unresolved signal. If you assume that the designer can have a brain fart and try to drive signal 'XYZ' from two processes then you also have to accept that the same designer could have two equations for 'XYZ' in the 'one' process. Assume for the moment that one of those two is correct. If those two equations are in separate processes the compiler immediately flags it as an error, if they are all in one process then you've basically priority encoded those two equations. Since we assumed that the designer had a momentary brain fart forgetting about the other assignment that already existed, which method allows you to fix the bug quicker? > >> Output register variable values > >> are assigned directly to out ports. > >> > > And this is better (or just different) than output register signals > > values being assigned to out ports? > > Simpler because *all* of my registers are variables. > There is no need to interpose a signal. Just > > my_out_port <= my_out_reg_v; > > I'll go with just 'different' on this one, it doesn't seem better, worse or simpler to me since the only reason for that line of code is because the probably more logically complicated assignment that occurs to the variable could just as easily have assigned it to the output signal in the first place. But there are times when even I use variables inside a clocked process too so I don't really disagree. KJArticle: 105498
baboonspanker@fastmail.fm wrote: > I see that Xilinx claim 0.92 Dhrystone 2.1 mips/Mhz for Microblaze and > Altera varously up to 1.2 dmips/Mhz. Does anyone know if these are > measured with inlining enabled? I found Xilinx XAPP507 which implies > that their headline "DMIPS" figure for the embedded powerPCs is with > inlining enabled but I can't find anything similar for the soft cores. > Can't say for Altera but for MicroBlaze we disable inlining while doing dhrystone benchmarks since the idea behind the dhrystone benchmark requires a percentage of procedure calls. Inlining would remove that. I think it would violate the main idea behind the dhrystone benchmark. We get a higher DMIPS/MHz if we allow inlining. And to make sure that no inlining is done we compile with the '-fno-inline' flag to GCC. If we don't have that flag, the amount of inlining depends on the version of GCC since they difference in the amount of inlining. Göran BilskiArticle: 105499
Siva Velusamy wrote: > 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? > > Frank Hello Frank, Siva, I am also working on chipscope but it doesn't work. The error message is very strange and I suppose it is an assertion error. I use EDK8.1 SP2, ISE8.1 SP3 and Chipscope 8.1SP3. Can you tell me what is your configuration? Thanks a lot. Sunwei
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