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
c d saunter wrote: > Brian Drummond (brian_drummond@btconnect.com) wrote: > > : uh, in what way is C a higher level language than VHDL anyway? > > I guess that's a bit like comparing apples and oranges if we are talking > about the *synthesizable* part of VHDL. Actually you've got me sat here > scratching my head trying to decide now. > > There are constructs that aren't present in VHDL / or don't synthesize > that I consider a higher level - e.g. things like C structs allow many > variables to be passed around between areas of C code, without everything > area (function) having to be upadated if (for example) extra variables are > added to the struct. I don't think VHDL has such a neat, clean way of > doing this. Yes - also I believe VHDL is matching a full "include" mechanism, wheras both C and Verilog have this. Perhaps it's abusive to do so, but that can be used to abstract out all sorts of stuff.Article: 96201
cs_posting@hotmail.com wrote: > c d saunter wrote: > > Brian Drummond (brian_drummond@btconnect.com) wrote: > > > > : uh, in what way is C a higher level language than VHDL anyway? > > > > I guess that's a bit like comparing apples and oranges if we are talking > > about the *synthesizable* part of VHDL. Actually you've got me sat here > > scratching my head trying to decide now. > > > > There are constructs that aren't present in VHDL / or don't synthesize > > that I consider a higher level - e.g. things like C structs allow many > > variables to be passed around between areas of C code, without everything > > area (function) having to be upadated if (for example) extra variables are > > added to the struct. I don't think VHDL has such a neat, clean way of > > doing this. > > Yes - also I believe VHDL is matching a full "include" mechanism, > wheras both C and Verilog have this. Perhaps it's abusive to do so, > but that can be used to abstract out all sorts of stuff. er, s/matching/lackingArticle: 96202
Mike Treseler (mike_treseler@comcast.net) wrote: : In vhdl, this is called a record, and records work fine for synthesis. : See type retime_t in the reference design below. : A vhdl single process design can also handle variables : "to be passed around between areas of code". : Note how the variable TxState_v : is accessed by the both of the : procedures cpu_regs and tx_state : in the reference design below. : http://home.comcast.net/~mike_treseler/uart.vhd Hi Mike, Once again I stand corrected and wiser - thanks for the example! Now if only there was an include statement as well to let the shared definitions reside in a seperate file... Cheers, ChrisArticle: 96203
cs_posting@hotmail.com wrote:
>>Yes - also I believe VHDL is lacking a full "include" mechanism,
>>wheras both C and Verilog have this. Perhaps it's abusive to do so,
>>but that can be used to abstract out all sorts of stuff.
The downside is that a preprocessor allows
a new category of bugs that are immune
to regression testing at simulation time.
-- Mike Treseler
Article: 96204>Now if only there was an include statement as well to let the shared >definitions reside in a seperate file... cpp works fine on non-c text files. Shouldn't take too much hacking if you use make rather than a gui. -- The suespammers.org mail server is located in California. So are all my other mailboxes. Please do not send unsolicited bulk e-mail or unsolicited commercial e-mail to my suespammers.org address or any of my other addresses. These are my opinions, not necessarily my employer's. I hate spam.Article: 96205
On Tue, 31 Jan 2006 15:59:23 +0000 (UTC), christopher.saunter@durham.ac.uk (c d saunter) wrote: >Brian Drummond (brian_drummond@btconnect.com) wrote: > >: uh, in what way is C a higher level language than VHDL anyway? > >I guess that's a bit like comparing apples and oranges if we are talking >about the *synthesizable* part of VHDL. to which the obvious answer would be to compare the synthesizable subset of VHDL with the synthesisable subset of C ;-) >There are constructs that aren't present in VHDL / or don't synthesize >that I consider a higher level - e.g. things like C structs allow many >variables to be passed around between areas of C code, without everything >area (function) having to be upadated if (for example) extra variables are >added to the struct. I don't think VHDL has such a neat, clean way of >doing this. Records. There's nothing fundamentally not-synthesisable about them, though tool support may be spotty. They aren't quite as useful as I would like, because (AFAIK) all elements in a record must share some characteristics like port directions; e.g. address and strobe can share a record (they are both outputs from my module), but data (bidirectional) and ack (input) cannot. But port directions would pass over the head of something C-like anyway. >As I said before 'Why AnythingC' - I don't think it's high enough 'above' >VHDL to make the pain of using a sequential orientated language for >programming FPGAs worth while. I'm a long way from convinced it's _as_ high. If you need a sequential oriented language - it's right there in VHDL; just don't leave the current process. If you need to support concurrency, I wouldn't choose C. If you need to cleanly separate interfaces and implementations, I wouldn't choose C. If you want to perform arithmetic on access types (aka pointers), I grant you, that's another matter... All that being said, I wouldn't like to write a word processor in VHDL. But even that could be argued that's a compiler and library issue, rather than a language issue. - BrianArticle: 96206
On Tue, 31 Jan 2006 20:14:42 +0000 (UTC), christopher.saunter@durham.ac.uk (c d saunter) wrote: >Mike Treseler (mike_treseler@comcast.net) wrote: > >: In vhdl, this is called a record, and records work fine for synthesis. >: See type retime_t in the reference design below. > >: A vhdl single process design can also handle variables >: "to be passed around between areas of code". >: Note how the variable TxState_v >: is accessed by the both of the >: procedures cpu_regs and tx_state >: in the reference design below. > >: http://home.comcast.net/~mike_treseler/uart.vhd > > >Hi Mike, > Once again I stand corrected and wiser - thanks for the example! > >Now if only there was an include statement as well to let the shared >definitions reside in a seperate file... sounds like a package! :-) - BrianArticle: 96207
g14g2000cwa.googlegroups.com>, gallen wrote: > > When I can get a 1 GHz FPAA for $10, then there may be a market. Chances are because people tend to go ADC -> FPGA -> DAC and use digital algorithms to massage things. -- [100~Plax]sb16i0A2172656B63616820636420726568746F6E61207473754A[dZ1!=b]salaxArticle: 96208
On Tue, 31 Jan 2006 16:39:58 +0100, "brian" <bhb22l@yahoo.fr> wrote: >Hi all, > >I need a VHDL source code scrambler/descrambler. >Polyn : x ^ 7 + x ^ 6 + 1 > >I found some information on web (LFSR xilinx, etc...), but I have some >problem with my example. > >Thanks a lot for any reply about this subject (web, litteratur,vhdl >code...). >Brian That's the SONET/SDH scrambler polynomial. I guess it could be also used in other applications. Data rates vary from 50-ish Mb/s to 40Gb/s. The rate will determine the sort of hardware implementation. Can you tell us a little more about your application? Things like data rate, bus width, clock rate, whether the scrambler needs to be reset (it does for SONET), whether the receiver has a self synchronising descrambler, etc. Xilinx XAPP651 might give you some ideas. http://www.xilinx.com/bvdocs/appnotes/xapp651.pdf Regards, AllanArticle: 96209
Hi Antti, On the Linux vs windows workstation issue, we are almost evenly split here in our group. I do everything (ISE, EDK, uClinux, ...) on a Linux box, running CentOS3 (perfectly compatible with Xilinx tools). I do have an old Windows laptop for running MS Office and web/email but that's about it. Others in the group are running CoLinux, some on laptops, and they run all of the tools in that environment. CentOS 3 installs just fine in CoLinux, so the entire Xilinx tool flow can occur in a virtual Linux PC. One of our brainy guys hacked colinux to tunnel the parallel port, so we run impact inside CoLinux with vanilla Xilinx drivers - it couldn't be much easier. The decision to not support Windows (Cygwin) for MicroBlaze uClinux development is a difficult one, but justified I believe by experience in the misery of Cygwin. Cygwin is just enough like Linux to make you think "it should work", but just different enough to make life miserable. Some of these restrictions come from underlying Windows crud, like case insensitive filesystems, poor handling of file permissions, that sort of thing. Linux sees a difference between 'makefile' and 'Makefile' - windows can't. While nobody would recommend overloading filenames in this way, there's not a lot that can be done about it retrospectively without (IMO) inordinate effort. It's also dreadfully slow - compile times can be on the order of 2-3 times longer. Anyway, perhaps we should package up our CoLinux environment a bit better and distribute it, it might make life a bit easier for people in your position (and those stuck in MS Windows corporate environments). Regards, John Antti Lukats wrote: > "John Williams" <jwilliams@itee.uq.edu.au> schrieb im Newsbeitrag > news:newscache$i5fxti$dj2$1@lbox.itee.uq.edu.au... > >>Antti Lukats wrote: >> >> >>>I just love how easy it is to port uClinux to new platform, just >>>change the UCF file and there you go :) >> >>You know Antti, in a very strange way you can take some credit for that >>fact. Your statement in a comp.arch.fpga posting 18 months ago >> >>http://groups.google.com.au/group/comp.arch.fpga/browse_frm/thread/97f020e714a25237/2a12c984240d22e8?tvc=1&q=lukats+uclinux#2a12c984240d22e8 >> >>"NIOS uCLinux is WAY easier to get started then MicroBlaze uCLinux >>thanks to the full integration of the config and integration into >>Eclipse workbench, as EDK6.3 is also Eclipse based it would be possible >>todo the same for MicroBlaze uClinux config and build. " >> >>p***ed me off so much I went and created the auto-config mechanisms that >>now make mb-uclinux by far the easiest (and probably most popular) >>soft-CPU Linux solution around. >> >>So, thanks - I think :) >> >>John > > > Oh John, > > sorry when I got you pissed off. > > you know I am happen to so poor guy that I can not afford to have second > workstation only for MicroBlaze development and as you know the MicroBlaze > uClinux build until today can not be done on the Windows machine. > > So what I stated 18months ago stands so far that it is (or was at least) > possible to configure and and build uClinux on single Windows PC a nice to > have thing for poor souls like me not having separate linux PC box around. > > OTOH - I did only check the uClinux config from SOPC builder, it worked, but > I have never ever seen it working as I do not happend to have NIOS uClinux > ready hardware ready and hasnt cared enough to obtain such hardware so far > either. > > And I have build uClinux systems way before the auto-config, and it has been > always been easy for me (after the first try). > > I have spent a lot of time in desperate attempts to get coLinux environment > setup with preconfigured microblaze uClinux toolchain after some pain it > works but the way todo file transfer to windows host PC is real complicated, > so only ysterday (or today if in US timezone) I did install Bochs source > code and compiled Bocs x86 emulator on Windows for one simple reason: > > to have windows based virtual linux with pre installed images containing > MicroBlaze toolchain and uClinux deve tools - so other poor guys (those with > no Linux!) can also work on single PC and still develop for uClinux > Microblaze > > and again just today I got finally working a MicroBlaze uClinux FPGA tested > driver for SD Cards so I was able to mount in MicroBlaze uClinux a SD card > formatted with FAT16 and after mount I did see files on the card. > > its FAST bit.banged software driver that works with SD (later I may add MMC > card support too) cards in NON-SPI mode. It can work with any software > controllabe PIO port, currently with GPIO CMD-DAT-CLK-card sense onto port, > all other is software. > > a small bootloader exists that loads the full uClinux image from SD card > using the same bitbang mode, load time approc 7seconds. This could be even > better as I have not done assembly level optimization to the code yet. > > I am replying in such details as I was just about to contact you to ask what > is the procedure to submit the driver to be included in the uClinux > distribution (it is GPL licensed) > > John, dont judge me so hard, for those who primare work on linux its really > hard to understand how much trouble it is setting up and maintaining 2 work > stations for the linux cross compile. I just want to type > > make menuconfig > make dep > make > > from my primary workstation (winPC) > > as long as that is not possible, well it means additioal burden - at work I > did today the following procedure 18 times > > 1 edit mmc.c > 2 TFTP PUT mmc.c > 3 stand up from my chair going to linux PC here working standing > 4 copy from tftpboot to \drivers\block > 5 make > 6 back to my workplace, sitting down > 7 TFTP GET image bin > > 8 copy image.bin to SD card, insert to FPGA board, reset 10 seconds linux > prompt is ready :) > > I have a mouse-keyboard-switch, but linux doesnt work with it :( I really > have killed pretty much of my time because of no easy solution exist for > those whose primary system is windows - and that has to be so as FPGA tools > are generically better supported on WinXP then linux so switching to linux > completly is not an option for me. > > anyway I am hoping to have the BOCHS emulator setup to provide a solution > that doesnt require the purchase of second PC for microblaze uclinux > development > > cheers > Antti > >Article: 96210
That was an error in my design. I hope to run it at 3.3V in the next revision. That would have made things much easier. YajuArticle: 96211
Austin Lesea <austin@xilinx.com> writes: > There is nothing "open source" about any of Xilinx's software. Then why did the installer made me agree to the GPL and LGPL? I thought it was because Xilinx's software (ISE Foundation) included some open source software.Article: 96212
Brian Drummond wrote:
> I'm a long way from convinced it's _as_ high.
>
> If you need a sequential oriented language - it's right there in VHDL;
> just don't leave the current process.
>
> If you need to support concurrency, I wouldn't choose C.
>
> If you need to cleanly separate interfaces and implementations, I
> wouldn't choose C.
I wouldn't choose VHDL either :)
But it does come down to personal preferrence and what you
are used to programming in. The following example compiles in
to about a 100 or so LUT/FF's in the beta-2 soon to be released
for FpgaC. The WHOLE process block is concurrent, with
sequential symantics for variable reuse.
So, we have implict concurrency for pipelining, bit level control
for a bit serial design, that maps directly to 3 stages of 9 bits,
with input and output ports (which could have had pins assigned
as a LOC attribute), and a structured interface description which
could be placed in a project include directory for reuse between
design files.
So, what's the point other than a religious war of my language is
better than your language without an specific metrics other than
personal judgement?
/*
* BitSer.c - FpgaC Pipelined Bit Serial Sort Example 1
* copyright 2006 by John Bass, DMS Design under FpgaC BSD License
*
* This example builds a pipelined merge sort for bit serial unsigned
* integers, using LUT based multiplexors. The sort happens in log2(N)
* stages, with a log2(N) latency thru the pipeline. The muxes each
* check the data relationship, and latch the sort mswap mux selector
* at the first inequality until endword is seen.
*
* One variation of this design is to buffer the bit serial words into
* LUT rams and return the sorted data on the same I/O pins. In FpgaC
* that would be a stage of small arrays for retiming. This would allow
* a sorting engine with X pins to sort unsigned bit serial integers of
* length N in time 2*N clocks, and a latency of N clocks.
*
* Another variation of this design is to fill the FPGA with additional
* stages and make the internal sort wider than the available I/O pins
* in support of a much larger streaming sort with multiple passes. The
* additional array memory and sorting muxes would form a bubble sort
* that would carry that many words down thru the stream.
*
* Other variations are changing the word flag to the first bit, to
clear
* the mux selectors.
*/
/*
* Pipeline 8 streams of bit serial data words
*/
struct stage {
int s0:1; // stream 0
int s1:1; // stream 1
int s2:1; // stream 2
int s3:1; // stream 3
int s4:1; // stream 4
int s5:1; // stream 5
int s6:1; // stream 6
int s7:1; // stream 7
int endword:1; // sentinal to reset mux selector, active high
} in, p1, p2, out; // pipeline stages
/*
* Setup I/O port mapping
*/
#pragma inputport (in.s0)
#pragma inputport (in.s1)
#pragma inputport (in.s2)
#pragma inputport (in.s3)
#pragma inputport (in.s4)
#pragma inputport (in.s5)
#pragma inputport (in.s6)
#pragma inputport (in.s7)
#pragma inputport (in.endword)
#pragma outputport (out.s0)
#pragma outputport (out.s1)
#pragma outputport (out.s2)
#pragma outputport (out.s3)
#pragma outputport (out.s4)
#pragma outputport (out.s5)
#pragma outputport (out.s6)
#pragma outputport (out.s7)
#pragma outputport (out.endword)
/*
* Define C Preprocessor macro for basic sorting mux engine
*/
#define mux(stagein, stageout, s1, s0) { \
int mlatch:1, mswap:1; \
if(~mlatch & (stagein.s1 ^ stagein.s0 )) { \
mlatch = 1; mswap = stagein.s0; \
} \
if(mlatch && mswap) { \
stageout.s1 = stagein.s0; stageout.s0 = stagein.s1; \
} else { \
stageout.s1 = stagein.s1; stageout.s0 = stagein.s0; \
} \
if(stagein.endword) \
mlatch = mswap = 0; \
}
/*
* An FpgaC process is started up when the bitstream is configured
* and processes implicitly loop forever
*/
process Sort() {
/*
* To build a pipeline, we describe the last stage first,
* and the first stage last. Thus as execution proceeds
* logically down this procedure, stage n gets it's data
* form stage n-1 below till we get to the device input
*/
// Pipeline Stage 3: Sort stage 2 to output pins
mux(p2,out,s7,s3);mux(p2,out,s6,s2);mux(p2,out,s5,s1);mux(p2,out,s4,s0);
out.endword = p2.endword;
// Pipeline Stage 2: Sort stage 1 to stage 2
mux(p1,p2,s7,s5);mux(p1,p2,s6,s4);mux(p1,p2,s3,s1);mux(p1,p2,s2,s0);
p2.endword = p1.endword;
// Pipeline Stage 1: Sort input pins to stage 1
mux(in,p1,s7,s6);mux(in,p1,s5,s4);mux(in,p1,s3,s2);mux(in,p1,s1,s0);
p1.endword = in.endword;
}
Article: 96213Brian Drummond wrote: > But port directions would pass over the head of something C-like anyway. Been in TMCC/FpgaC for 10 years .... tristate I/O.Article: 96214
Take a look at the docs for the Texas Instruments 74LS297. I used it in a project many years ago, it worked amazingly well (multiplying the pulses from a shaft encoder by 20 times.) I don't know if it is produced anymore, but all you want is the documentation, which was in the TI 74LS series databook. They give a pretty thorough description of how the thing works in the data sheet. Jon Gopi wrote: >I need material wchich cover all about ADPLL, which contains about >operating principles and design (vlsi also). If there are any links >that have these information please let me know > > >Article: 96215
Antii, Thanks for you reply. I tried all your suggested options. I am having even more bizzarre issues. I modified my process as Verified that the startup clock is set to CCLK (as a part of Implementation option of the XST synthesis tool). 1. assert FPGA PROG# pin low. 2. De-assert PROG# high. 3. wait for INIT# to go high. 4. Unpack the byte (into bits) from configuration file (BIN file) and place first bit (LSB) of bitstream on DIN. 5. pulse CCLK high then low. 6. repeat 4, 5 for remaining bits of bitstream. While doing this monitor the INIT# line. If it goes low, the FPGA has detected a bitstream error. 7. place 1 on DIN. 8. pulse CCLK high then low. (for like 10 dummy clock cycles). The DONE goes high after like 30 seconds (after configuration has ended) or something, but my actual code (LED blinking) never happens. And then after another 30seconds later the DONE goes low!!!!! So I connected the JTAG pins and used IMPACT to read the status register. These pins were different from succesful JTAG configuration. status of GTS_CFG_B : 0 status of GWE : 0 status of GHIGH : 0 And the INIT_B was high and DONE was low. Any ideas!!!!!!!! -YajuArticle: 96216
Gopi wrote: > I need material wchich cover all about ADPLL, which contains about > operating principles and design (vlsi also). If there are any links > that have these information please let me know Have you checked out: "Phase-Locked Loops", Roland E. Best ISBN: 0071349030Article: 96217
Nils wrote: > After translating the design an error message is displayed as follows: > ERROR:Portability:90 - Command line error: Switch "-quiet" is not > allowed > > Do I have to change any setting for the NGDBuild Option? Check out the DefaultScript_Xilinx_MAP.txt file in the System directory of your Altium installation. I believe you can comment-out this option with "#"... not that I've tried it myself. Failing that, try the DXP forums at Altium.com. Regards, MarkArticle: 96218
So, back to the question of worst case designs for supporting RC. What are the worst case VccInt currents that various packages will handle? How does that relate to what is necessary for balancing the design across multi phase clocks to spread the current spikes following clock edges in time? Is there any means to get a handle on the current time spread profile by knowing the distribution of routing lengths and logic depths for each clock? I assume ground pads are shared between VccInt and I/O? If so, how would one combine worst case VccInt ground currents with the worst case I/O ground switching currents for a worst case package level design spec?Article: 96219
Allan Herriman wrote: > Can you tell us a little more about your application? Things like > data rate, bus width, clock rate, whether the scrambler needs to be > reset (it does for SONET), whether the receiver has a self > synchronising descrambler, etc. ...how many credit points it's worth...Article: 96220
I have a 10BASE-T MAC/stack design (using PicoBlaze, BTW) which I'm trying to bring up on the Avnet/Memec S3MB Spartan3 1500-based board. I've got the board connected to a PC, nothing else, running "ping" and Ethereal. The S3MB board pins-out the Rx and Tx lines the reverse of the PC, so I am using a straight-thru cable. My design receives ARP and ICMP ECHO frames from the Broadcom BCM5221 (jumpered to not autonegotiate, and keeping it at 10Mbps) quite happily (haven't noticed any dropped frames, and it even properly ignores test frames with the incorrect IP address). But the PC appears to reject most of the frames with which my design replies. I can see my response frames at the MII, and I see the wire wiggle with Manchestery goodness (voltage levels for receive and transmit frames are about the same). But 80-90% of the time, my transmissions are not detected, both by ping (timeout) or Ethereal. I've checked my checksums and FCS, and they appear correct. In fact I don't see much besides header checksums and seqs or idents that are different between accepted and rejected frames. I limit the changes on the MII TxD and TxEN lines to when TxC is low. What else can I be doing wrong at this level? Does anyone have a reference design that responds to pings that I can pop into this card to see how it behaves? twv@Article: 96221
John Williams wrote:
[ ... ]
> Some of these restrictions come from underlying Windows crud, like case
> insensitive filesystems, poor handling of file permissions, that sort of
> thing. Linux sees a difference between 'makefile' and 'Makefile' -
> windows can't.
I don't want to create a long off-topic thread about it, but Windows is
entirely capable of distinguishing case in file names. See the
documentation for CreateFile, specifically FILE_FLAG_POSIX_SEMANTICS,
(e.g. at
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/createfile.asp)
for more details.
Given the basic nature of Cygwin, I'd have expected its implementation
of creat and/or open to include this, and just about everything else
should run on top of that, but perhaps not -- I haven't looked at its
source code recently to check.
> While nobody would recommend overloading filenames in
> this way, there's not a lot that can be done about it retrospectively
> without (IMO) inordinate effort.
I'm not sure what constitutes inordinate, but I'd expect the effort to
be relatively minor. There shouldn't be many places that need changing
(quite possibly only one), and most of the software running on cygwin
expects case-sensitive file names anyway, so it doesn't seem like this
change would be likely to break much of it.
--
Later,
Jerry.
Article: 96222On 31 Jan 2006 15:02:01 -0800, fpga_toys@yahoo.com wrote: > >Brian Drummond wrote: >> I'm a long way from convinced it's _as_ high. >> >> If you need a sequential oriented language - it's right there in VHDL; >> just don't leave the current process. >> >> If you need to support concurrency, I wouldn't choose C. >> >> If you need to cleanly separate interfaces and implementations, I >> wouldn't choose C. > >I wouldn't choose VHDL either :) For the last of these points, or all of them? Do you think C's include mechanism is somehow more reliable than use clauses? ... or makes it easier to identify the source of a name-clashing entity? >So, what's the point other than a religious war of my language is >better than your language without an specific metrics other than >personal judgement? Just a little bit more than personal judgement; the claim I was questioning was whether C was a higher level language - NOT that it was somehow "better" in someone's personal judgement - which is a matter of preference and familiarity. (So far the concrete examples of VHDL's failures happen to be things it does fine, like records, or even better than C, like "use" and packages instead of includes, but let's wait and see) > * This example builds a pipelined merge sort for bit serial unsigned > * integers, using LUT based multiplexors. The sort happens in log2(N) > * stages, with a log2(N) latency thru the pipeline. okay... I see lots of instantiation of individual entities, but no higher level abstraction. But I may be missing something. For example, if n happens to be something other than 8, do you have to re-write it extensively, and get every parameter invocation right in every instance in the new version, or do you change a single generic, and let "generate" do all the work of creating a correct design? - BrianArticle: 96223
S. Hagenkoetter wrote: > I am trying to build an interface to a Analog Devices AD5447 digital analog converter > on Xilinx Virtex-II 1000 and 3000 FPGAs. First the interface seems to work because the > DAC outputs a sinus signal as supposed to do. Now as the design is getting bigger more > and more noise is shown on the dac output. So I think this is related to timing > issues concerning the dac interface. If design size is affecting your output timing, it sounds as if your data is not using the registers in the IOBs. Have a look inside both your data and clock IOBs in the FPGA editor. If the output FF in the IOB is not used, you need to alter your ISE settings to allow packing registers into IOBs. If you are using XST for synthesis, start by setting the Xilinx Specific Option "Pack I/O Registers into IOBs" (in the XST property pages) to YES. There are possibly a few more switches in the other tools, look through them. > > Thanks for your help. Hope this helps. Regards, Just John > > Best regards, S. Hagenkoetter.Article: 96224
Brian Drummond wrote: > For the last of these points, or all of them? Do you think C's include > mechanism is somehow more reliable than use clauses? ... or makes it > easier to identify the source of a name-clashing entity? Name clashing isn't normally a problem for C programmers, as it generally only happens in global naming, and then relatively rarely. > Just a little bit more than personal judgement; the claim I was > questioning was whether C was a higher level language - NOT that it was > somehow "better" in someone's personal judgement - which is a matter of > preference and familiarity. There are two reference points there, depending on if you are comparing the two by their "highest level of abstraction" or the two by their "lowest level of abstraction", combined with the problem of just what do you consider an abstraction. And a more thorny problem of how you wieght features on that scale. Clearly VHDL, Verilog, and C are generally equivalent for the basics of booleans and arithmetics as languages (with a few minor hickups). Real functions, procedures, and the like are one of several higher levels of abstraction that you might judge an HLL over and HDL. The ability of C to partition a design between LUT's (using netlists), Virtual Machines (compiled to pop codes or other VM machine codes), general purpose processors, or even highly specialized parallel processors would generally suggest that the language isn't directly tied to the lowest levels of abstraction which would prevent or hinder such portability, and thus maintain an overall higher level of abstraction. C has complex state machine functions in the form of looping combined with conditionals and function invocations, which are natural for traditional programmers, and a higher level of abstraction that what you generally have available in an HDL to evoke the same state machine and process flow. But that is not what I was responding to. What I was responding to was your list of things you were asserting a C based HLL netlist compiler was in your mind significantly poorer at, or completely missing. Concurrency, Bus I/O's, reusable design elements/interfaces, etc ... which are different in C, but not significantly inferror ... as which is best, is clearly a judgement call based on preferences. > okay... I see lots of instantiation of individual entities, but no > higher level abstraction. But I may be missing something. > > For example, if n happens to be something other than 8, do you have to > re-write it extensively, and get every parameter invocation right in > every instance in the new version, or do you change a single generic, > and let "generate" do all the work of creating a correct design? We tend to do that in C with scripting. Something I frequently see done for VHDL/Verilog as well to generate optimized arrays of functional blocks. The implict looping functions to replicate arrays of logic blocks isn't generally enough to complete the additional logic that wider or more complex arrays of logic blocks may need, for anything other than a simple bus width change. So, this is a very slight advantage for certain classes of reuable design elements that applications targeted for C don't generally need.
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