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 forgot mention that i did a static timing analysis with the timing analyzer. i also looked into the manual for trace but i would rather have some examples if there are some. thanksArticle: 130351
Jecel wrote: > On Mar 20, 6:45 am, Kolja Sulimma wrote: > >>>[I suggested the Transputer] >> >>Or something similar, more modern: <intellasys> >>9mW per core at 1GHz. > > > Well, a FPGA version wouldn't get anywhere near these kinds of > numbers. But I do agree that MISC variations are a very good idea (I > have done some myself and others have suggested some in this thread). > A key MISC feature, the loading of several instructions in a single > memory access, would be missing from a serial implementation, however. > > As additional sources of inspiration I would like to mention the > control computer for the Minuteman missile: > > http://en.wikipedia.org/wiki/D-17B > > and the Kenbak-1 (considered by many as the first personal computer > since it sold for $700 in 1971): > > http://en.wikipedia.org/wiki/Kenbak-1 > http://www.bitsavers.org/pdf/kenbak/ > > The documentation for the Kenbak includes a detailed explanation of > how it works as well as all the schematics. It only addressed 256 > bytes (in a shift register - not RAM), but otherwise is a pretty neat > design. > How about the LGP-30 or RPC-9000? 30-bit words, 4K store, multi-address, 16 instructions IIRC, and Algol, Dartmouth Basic, realtime control apps etc. MichaelArticle: 130352
On Mar 20, 2:48 pm, Dave Pollum <vze24...@verizon.net> wrote: > On Mar 20, 2:11 pm, Dave Pollum <vze24...@verizon.net> wrote: > > > I'm trying to run the Xilinx version of Modelsim (XE III 6.2g), and it > > displays everything in HUGE fonts. On my 21" monitor, each char is at > > least 1" tall. This happens whether I run Modelsim by itself, or when > > I run it from ISE Webpack 9.2.04i. I've downloaded the latest > > versions of both ISE Webpack and Modelsim XE from Xilinx's web site. > > I tried searching Xilinx's website but didn't find any answers. If I > > can find an older version of Modelsim, I'll try that, but I'm not sure > > where to download it from. > > TIA > > -Dave Pollum > > I forgot to mention that I'm running Windows 2000 Prof, SP4. > -Dave Pollum I uninstalled the video card and then re-installed the video card software. When I ran Modelsim (stand alone), the fonts were correct. But the second time I ran Modelsim, the fonts were huge again. As before, the character fonts had large pixels. -Dave PollumArticle: 130353
On Mar 20, 7:25 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > Really!? What's the point of the LOCKED output then? Do that flaw not > make them a bit useless? That's kind of what I thought, too :-( - KennArticle: 130354
Hello, I am puzzled by a statement in a book I am reading: To avoid combinational feedback during synthesis, a while loop must be broken with an @(posedge/negedge clock) statement, such as this while (!done) begin @(posedge clk); counter = counter + 1; end I searched combinational feedback, I found it usually happens when a code only has 'if' branch (missing the else branch) and unexpected behavior could happen if the condition is always false. Does it apply here that maybe done is always false? How does '@(posedge clk);' avoid this combinational feedback? FeiArticle: 130355
On Mar 20, 7:25 am, Martin Thompson <martin.j.thomp...@trw.com> wrote: > kennheinr...@sympatico.ca writes: > > - Xilinx DLLs and DCM tend to exhibit peculiar behaviour in that their > > LOCK output can assert even though the output clock is completely > > unstable, or possibly just running at a harmonic, like half-rate. > > Really!? What's the point of the LOCKED output then? Do that flaw not > make them a bit useless? > > Cheers, > Martin > > -- > martin.j.thomp...@trw.com > TRW Conekt - Consultancy in Engineering, Knowledge and Technologyhttp://www.conekt.net/electronics.html I thought so, too :-( And in case anyone thinks I'm making this up, see for example Xilinx answer record #9451 (Virtex-2), containing the magic words: "...the DLL will produce an unreliable lock signal and unreliable output clock. To recover from this condition, the DLL must be manually reset." Or Answer record #30306 (Spartan): "The LOCK output is to indicate when the DCM outputs are valid. In some cases it may not go LOW to indicate the DCM has lost lock." ..and I'm sure there are many others. This is not an attempt to slag Xilinx, I'm just pointing out something to watch for. It's an instance of one of my pet peeves, that in 99.999 percent of cases, an analog "thing" (like locked-ness, or signal level, or sync pulse detection, or what have you) gets done wrong up (often by design oversimplifications) when translated into a digital "true/false" output. PLL lock signals are classic examples, as are the outputs of video sync separators. This is digressing from pure VHDL, so I'll stop while I'm ahead. - KennArticle: 130356
http://www.edn.com/article/CA6543758.html http://www.synplicity.com/corporate/pressreleases/2008/synopsys_acq.html Aaack, I'm having those awful FPGA Express flashbacks again....Article: 130357
Brian Davis wrote: > http://www.edn.com/article/CA6543758.html > http://www.synplicity.com/corporate/pressreleases/2008/synopsys_acq.html > > Aaack, I'm having those awful FPGA Express flashbacks again.... Oh dear God. And here I was just talking with our great Synplicity reps today at our local Xtech. Things seemed okay with them - no news, no worries. Say it ain't so, Joe... - John_HArticle: 130358
Hi all, just got Xylo-LM board (Spartan3E + FX2), I was searching for tips and tricks to avoid frying it. In particular, I was interested in interfacing with outside world. So far, I found that Spartan 3E is 5V tolerant if you put a 220Ohm series resistor but this would work only in input. What can I do to protect and make it fully 5V tolerant? If this is not possible, is there any DIL chip I could use to protect it? I also have this problem with i2c bus, but this is a little more complicated due to the bidirectionality of the signal. TIA, Giuseppe MarulloArticle: 130359
"Brian Davis" <brimdavis@aol.com> wrote in message news:3e148627-9d7c-4993-9fc2-c315c33dac44@8g2000hsu.googlegroups.com... > http://www.edn.com/article/CA6543758.html > http://www.synplicity.com/corporate/pressreleases/2008/synopsys_acq.html > > Aaack, I'm having those awful FPGA Express flashbacks again.... > I am not surprised, according to a 2005 Dataquest study 35% of ASIC designs are prototyped on FPGA's and I wouldn't be surprised if that number has doubled today. For this reason Mentor and Synplicity have spend a lot of R&D money to make ASIC netlist synthesis for FPGA's as easy as possible. In addition Synopsys gets the Hardi ASIC prototyping line. If you add to the mix the commoditisation of the lower/middle end of the synthesis market due to XST/QNS I wonder what direction Synopsys will take with Synplicity, Hans www.ht-lab.comArticle: 130360
On Thu, 20 Mar 2008 20:45:36 -0700, John_H <newsgroup@johnhandwork.com> wrote: >Brian Davis wrote: >> http://www.edn.com/article/CA6543758.html >> http://www.synplicity.com/corporate/pressreleases/2008/synopsys_acq.html >> >> Aaack, I'm having those awful FPGA Express flashbacks again.... > > > >Oh dear God. > >And here I was just talking with our great Synplicity reps today at our >local Xtech. Things seemed okay with them - no news, no worries. > >Say it ain't so, Joe... My take on this: - FPGA vendor tools (e.g. XST, Quartus) have improved to the extent that third party tools are no longer neccessary to get the most out of an FPGA. Synplicity is facing a shrinking market share if it sticks to the FPGA field. - Synopsys finally gets a VHDL compiler that doesn't suck. This may be a good thing for the VHDL language. (Assuming that Synopsys isn't going to stop VHDL development in Synplify.) Regards, AllanArticle: 130361
On Thu, 20 Mar 2008 17:23:03 -0700 (PDT), Fei Liu wrote:
>Hello,
> I am puzzled by a statement in a book I am reading:
>
>To avoid combinational feedback during synthesis, a while loop must be
>broken with an
>@(posedge/negedge clock) statement, such as this
>
>while (!done) begin
> @(posedge clk);
> counter = counter + 1;
>end
Not for the first time, a book that contains a statement that
is so misleading that it could reasonably be described as "wrong".
Consider what would happen if you did not have the clock event:
while (!done) begin
counter = counter + 1;
end
Now, let's imagine a simulator entering this loop when "done" is
false. It'll increment "counter" IN ZERO SIMULATED TIME, then
loop back and - surprise, surprise - "done" will still be false.
And so on. And the zero-time loop will prevent the simulator
from ever making forward progress through simulated time.
A synthesis tool might perhaps create a combinational
feedback loop as its best effort, but it really makes no
sense either for simulation or synthesis, and is a sure
way to get a simulator to lock-up.
Insert a clock delay in the loop, as your example shows, and
you start to get sensible behaviour. Test "done", find it's
false. Wait until the NEXT clock, increment the counter and
test "done" again. By that time, there has been plenty of
opportunity for other parts of the design or testbench to
modify the value of "done" so that the loop can exit.
Keep looping, testing "done" on each clock edge, until
eventually you discover "done" is true and your loop exits.
Note that this form of "implied state machine" coding is not
universally supported by synthesis tools, and is harder to
reason about than the traditional clocked coding style in which
a clocked process (always block) has exactly one @(posedge clock)
at its head. Implied state machines are also very troublesome
to reset. I mightily dislike them, even though they can be
shorter and superficially simpler for some kinds of sequential
design.
(Disclaimer: In the above paragraph, I'm talking about DESIGN
for synthesis. In a testbench, a completely different set of
concerns and compromises apply.)
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 130362fl <rxjwg98@gmail.com> writes: > Hi, > I am designing a bunch (about 100) of short length tap (5 taps each) > FIR. The tap coefficients would be many 1...31. I want to use > multiplier adder graph method for the multiplication. That is, > multiplying 15 will be implemented as left shift 4 bits, then minus > the original. I would like VHDL can intelligently select one of 16 > multiplication structure. Is that possible? Or, I have to write C code > to generate a VHDL doc? Are there other better methods? Thanks Just run it through synthesis with the coefficients in as constants. You'll be surprised (well, I was). When I had a long filter with small coefficients, I had to jump through hoops to get Synplify to use the hard multipliers instead of it being clever and doing shifts and adds! Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 130363
On Wed, 19 Mar 2008 14:29:58 -0700 (PDT), Jecel <jecel@merlintec.com> wrote: >Antti, > >my impression is that a subset of the 32 bit Transputers with a serial >implementation would be the best tradeoff in terms of complexity and >performance. The 3 element hardware stack and ALU would be very >compact on the FPGAs and the instruction set would give you reasonable >access to a block RAM (you don't want to write too much to a Flash and >it is nice to avoid reading random data from it to keep the >instruction stream flowing). > >Depending on how compatible it was (I wouldn't include the >multitasking and message sending stuff) you would have these languages >available for it: > >http://www.classiccmp.org/transputer/languages.htm > There's a similar instruction set (IIRC without message sending or much complexity devoted to multi-tasking) from the same era, which might be worth pursuing ... the Lilith, from ETH Zurich. Like the Transputer it would be considerably larger than a bit-serial machine, but probably more powerful. I wonder if you can still get a Modula-2 compiler for it... - BrianArticle: 130364
Giuseppe Marullo <giuseppe.marullospamnot@iname.com> wrote: >Hi all, >just got Xylo-LM board (Spartan3E + FX2), I was searching for tips and This one?? http://www.knjn.com/docs/KNJN%20FX2%20ARM%20boards.pdf >tricks to avoid frying it. In particular, I was interested in interfacing >with outside world. So far, I found that Spartan 3E is 5V tolerant if you >put a 220 Ohm series resistor but this would work only in input. >What can I do to protect and make it fully 5V tolerant? One possibility is to add a 5V tolerant buffer chip that works with 3.3V (LVTTL), which has the benefit of speed. Another one is the resistor one which for most cases are likely to be the most overall effecient. >If this is not possible, is there any DIL chip I could use to protect it? I >also have this problem with i2c bus, but this is a little more complicated >due to the bidirectionality of the signal. You can buy a simple chip packaged array of resistors to make sure nothing will overload the Spartan-3E. I suggest you have a look at the schematics of different developer boards. They often show how things should be done.Article: 130365
>My take on this: >- FPGA vendor tools (e.g. XST, Quartus) have improved to the extent >that third party tools are no longer neccessary to get the most out of >an FPGA. Synplicity is facing a shrinking market share if it sticks >to the FPGA field. >- Synopsys finally gets a VHDL compiler that doesn't suck. This may >be a good thing for the VHDL language. (Assuming that Synopsys isn't >going to stop VHDL development in Synplify.) They would only continue development if there's a incentive to do so. Minimizing competition tend to decrease the will to make good customer offerings (with exception of a few out-of-the-box thinkers). So are they too loose painfully if they screwup development? Is the management culture within Synopsys sound ..?Article: 130366
Jonathan Bromley wrote:
> On Thu, 20 Mar 2008 17:23:03 -0700 (PDT), Fei Liu wrote:
>
>
> Consider what would happen if you did not have the clock event:
>
> while (!done) begin
> counter = counter + 1;
> end
>
> Now, let's imagine a simulator entering this loop when "done" is
> false. It'll increment "counter" IN ZERO SIMULATED TIME, then
> loop back and - surprise, surprise - "done" will still be false.
> And so on. And the zero-time loop will prevent the simulator
> from ever making forward progress through simulated time.
> A synthesis tool might perhaps create a combinational
> feedback loop as its best effort, but it really makes no
> sense either for simulation or synthesis, and is a sure
> way to get a simulator to lock-up.
>
> Insert a clock delay in the loop, as your example shows, and
> you start to get sensible behaviour. Test "done", find it's
> false. Wait until the NEXT clock, increment the counter and
> test "done" again. By that time, there has been plenty of
> opportunity for other parts of the design or testbench to
> modify the value of "done" so that the loop can exit.
> Keep looping, testing "done" on each clock edge, until
> eventually you discover "done" is true and your loop exits.
>
> Note that this form of "implied state machine" coding is not
> universally supported by synthesis tools, and is harder to
> reason about than the traditional clocked coding style in which
> a clocked process (always block) has exactly one @(posedge clock)
> at its head. Implied state machines are also very troublesome
> to reset. I mightily dislike them, even though they can be
> shorter and superficially simpler for some kinds of sequential
> design.
>
> (Disclaimer: In the above paragraph, I'm talking about DESIGN
> for synthesis. In a testbench, a completely different set of
> concerns and compromises apply.)
Thanks for your explanation, now it makes sense to me. My brain is still
wired to think only in software sense. Another thing that I don't
understand is the disable command. In the following code example, the
'disable count;' statement does not break the loop (or maybe it's
reentered right away?)
Does always code_block causes code_block executed indefinitely even when
code_block is disabled? always and disable seem to contradict with
each other.
module mytest;
// wire x, y, c, d, b;
reg clock;
integer counter;
wire [3:0] a = 4'b0101;
assign b = c & d;
assign d = x | y;
initial
begin
counter = 1'b0;
clock = 1'b0;
forever #10 clock=~clock;
end
always @(posedge clock)
begin: count
counter = counter + 1;
if(counter == 1000) disable count;
end
initial
begin
$monitor("counter = %d", counter);
end
endmodule
Article: 130367hi i have a question. i have an edk project that i want to debug. so i inserted a chipscope core. my question now is if there is a way to look a signals not in the top level entities. for example i have an ip core connected to the fsl bus. but if i want to have a look at some signal withing the ip core i have to put some debug signals all the way up to the top level entity in my ip. is there another way to do that? thanks urbanArticle: 130368
On Mar 20, 3:19 am, Antti <Antti.Luk...@googlemail.com> wrote: > On 20 Mrz., 06:55, Jim Granville <no.s...@designtools.maps.co.nz> > wrote: > > > > > Frank Buss wrote: > > > rickman wrote: > > > >>Maybe I am missing something, but I have seen CPUs in FPGAs as small > > >>as 600 LUTs. I am pretty sure the picoBlaze is about that size. > > > > I think it is smaller, about 200 LUTs: > > > >http://www.embeddedrelated.com/groups/fpga-cpu/show/2028.php > > > And also the similar Mico8 ~240-323 LUThttp://www.latticesemi.com/products/intellectualproperty/referencedes... > > > >>A bit serial CPU might be smaller than an 8 bit CPU, but what is the > > >>driving need for something that small? 600 LUTs is not much in a 3000 > > >>LUT FPGA! > > > > Could be interesting to pack it in a Max II, where the smallest device has > > > 240 LEs. Sometimes you need some high speed logic and some more complex > > > tasks, but which can be low speed (keyboard sampling, output to LCD text > > > display). If you can get an additional low speed CPU for free, you could > > > save an external microcontroller. > > > The serial code memory is part of the appeal. > > FPGA cores are easy enough, but they are like stone soup, > > and you need to add code execution storage, = many pins, and EMC and PCB > > area issues. > > Single chip uC are a tough nut to crack, as they have FLASH+Analog, > > and higher volumes and growths than the FPGA sector. > > > -jg > > Hi all > > I wasnt online yesterday (was in Tirol/Austri-not for fun) so I answer > all in one > > "serial implementations of the past" - have worked with COP800 and I > had hard days optimizing DES for ST62T10 > - none of those is suitable directly, maybe there is something to look > and learn, but not much to direct use > > small FPGA soft-cores (existing ones) > - too large Until you tell us what "too large" means in numbers, we can't consider this requirement. > - not flexible in configuration options What flexibility do you require? > - no real C compilers exist That is not my understanding... What do you mean by "real"? > - can not address "flat word" 32bit addressing That is an interesting requirement. If you have a bit serial processor that executes, at best, 2 MIPS, why do you "require" a 32 bit flat addressing model? What is the application that needs 4 GB of address space? > now some additional considerations: > > 32 bit ALU for serial implementation cost the same as 1 bit ALU Not true. The overhead for control of a bit serial ALU is higher than the data processing and more complex than a parallel data path. There are happy mediums such as using an 8 bit core to perform 32 bit computations. > 32 bit registers if implemented in BRAM or data buffer of Atmel I don't know what this means. > Dataflash cost very little (0 FPGA fabric resource) Yes, anytime you go off chip, you are not using the FPGA fabric. > code data memory space cost very little, so opcode density is almost > least priority Code memory may be inexpensive, but the time to fetch is not low. This ends up being a limiter on the speed, but then you have already given up any speed requirements in the initial set of constraints. I'm not so sure of data memory. Are you talking ram or flash? > number of cycles per instruction is also very low priority (at least > for some optimization options) > > lets look sone special targets > > 1) device S3AN-50 > ============= > > if we use picoblaze, we use 30% of BRAM and some small % of FPGA, but > we only get 1KW of code and 8 bit processor/ALU You can always extend the code size by extending the processor to fetch from external dataflash. I don't think CPU cores are locked to the original implementation. Like I said above, an 8 bit processor can do 32 bit arithmetic very easily. > a S3/Dataflash optimized SPU could use Dataflash dual ram buffers for > registers,ram,stack those not use BRAM at all. Say it would run at 512 > clock per instruction, so what? It would be 32 bit processor with 0.1 > MIPS leaving ALL BRAMs to the user and almost all of the fabric as > well. And it would not cost anything extra as it the Dataflash is > already present in the S3AN > > 2) Actel A3P060/IGLOO60+SD card > ========================== > SPU should be configured to use half-BRAM for registes, ram,stack and > could be executing either from SD-card, again this would be 32 bit > processor with c compiler. Actel has no LUT ram option and any known > small 8 but softcore would already too be too large also. the code > memory price on SD card is virtually 0 > > 3) XXX + Winbond Quad SPI > ==================== > here we could also achieve some not so bad performance despite the > serialized code memory > > if all of the above special cases would be support by the same C > compiler (with settings to adapt to config differences) ? > > single chip MCU's are hard to crack, but that isnt the goal, in many > cases there are "unused" resources present, so the SPU could really > come virtually free, besides an extra IC + extra 0.80 USD is still > extra cost for additional MCU in the system > > AnttiArticle: 130369
There was also Hillis' Connection Machine from the 1980s. It was a massively parallel machine with 64k bit-serial processors, programmed in data parallel Lisp or C. While the processor was very simple, I recall the processor interconnection network was a bit more complex. -- Steve -- 3/21/08 "Brian Drummond" <brian_drummond@btconnect.com> wrote in message news:cq97u3h56a3g7dfe8ea434tdf4r6og7h4m@4ax.com... > On Wed, 19 Mar 2008 14:29:58 -0700 (PDT), Jecel <jecel@merlintec.com> > wrote: > >>Antti, >> >>my impression is that a subset of the 32 bit Transputers with a serial >>implementation would be the best tradeoff in terms of complexity and >>performance. The 3 element hardware stack and ALU would be very >>compact on the FPGAs and the instruction set would give you reasonable >>access to a block RAM (you don't want to write too much to a Flash and >>it is nice to avoid reading random data from it to keep the >>instruction stream flowing). >> >>Depending on how compatible it was (I wouldn't include the >>multitasking and message sending stuff) you would have these languages >>available for it: >> >>http://www.classiccmp.org/transputer/languages.htm >> > There's a similar instruction set (IIRC without message sending or much > complexity devoted to multi-tasking) from the same era, which might be > worth > pursuing ... the Lilith, from ETH Zurich. > > Like the Transputer it would be considerably larger than a bit-serial > machine, > but probably more powerful. > > I wonder if you can still get a Modula-2 compiler for it... > > - BrianArticle: 130370
Allan Herriman wrote:
> My take on this:
> - FPGA vendor tools (e.g. XST, Quartus) have improved to the extent
> that third party tools are no longer necessary to get the most out of
> an FPGA. Synplicity is facing a shrinking market share if it sticks
> to the FPGA field.
Yes, having once tried quartus 1.0, I am still surprised that
altera was able to catch up on language support and viewers.
Synplicity was already focusing on asic prototyping as
a result.
> - Synopsys finally gets a VHDL compiler that doesn't suck. This may
> be a good thing for the VHDL language. (Assuming that Synopsys isn't
> going to stop VHDL development in Synplify.)
I expect that the FPGA tools will be left intact,
but I would be pleasantly surprised if vhdl even shows up
on the fpga to synopsys asic design roadmap.
-- Mike Treseler
Article: 130371> It's probably not very good place for asking such, but there're should > be at least those who knows starting points. > We need to design our own CPU which can be very slow. It can execute > each instruction, let's say, up to 50 cycles. We don't care about > speed, and we are also don't care about memory size for microcode, but > we're really care about CPU unit size. Slow CPUs are usually also not very size efficient. > Where to read about CPU designing techniques, which are about shifting > all possible to microcode from CPU unit? Extreme case will be probably > Turing machine, but it's not practical. CPU registers and instructions > in our case should be looks like ARM9 processor, maybe. Maybe this is of interest, it recently found a new home: http://www.opencores.org/projects.cgi/web/mcpu/overviewArticle: 130372
referringto@googlemail.com wrote: > Maybe this is of interest, it recently found a new home: > > http://www.opencores.org/projects.cgi/web/mcpu/overview Nice small instruction set, but maybe too limitd, because even implementing a shift operation (e.g. for implementing multiplication) would need multiple instructions. And 64 bytes of data/code memory doesn't look very useful. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 130373
"Mike Treseler" <mike_treseler@comcast.net> wrote in message news:64i3hpF2c8abuU1@mid.individual.net... >> My take on this: >> - FPGA vendor tools (e.g. XST, Quartus) have improved to the extent >> that third party tools are no longer necessary to get the most out of >> an FPGA. Synplicity is facing a shrinking market share if it sticks >> to the FPGA field. > > Yes, having once tried quartus 1.0, I am still surprised that > altera was able to catch up on language support and viewers. > Synplicity was already focusing on asic prototyping as > a result. > I remember about nine years ago having to debug a complex (for the time) VHDL-based FPGA design that a colleague had synthesized using the synthesizer built into Altera MaxPlus II. He had already complained about the numerous, and seemingly simple, VHDL constructs he couldn't use because the Altera VHDL implementation didn't support them. I decided to try using Leonardo Spectrum instead (or whatever it was called back then) and to my horror discovered that his VHDL contained a number of totally illegal constructs that the Altera synthesizer had managed to do something with without as much as a warning. It turned out to be one of these illegal constructs that was causing the design to fail.Article: 130374
<u_stadler@yahoo.de> wrote in message news:313e6a67-a669-44cb-abd3-95910b9cc19c@59g2000hsb.googlegroups.com... > hi > > i have a question. i have an edk project that i want to debug. so i > inserted a chipscope core. my question now is if there is a way to > look a signals not in the top level entities. for example i have an ip > core connected to the fsl bus. but if i want to have a look at some > signal withing the ip core i have to put some debug signals all the > way up to the top level entity in my ip. is there another way to do > that? > > > thanks > urban Urban, Use the core inserter rather than the core generator. HTH., Syms.
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