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
Andreas Hofmann schrieb:
> Antti schrieb:
> > Andreas Hofmann schrieb:
> >
> >> Hello,
> >>
> >> i have created a fairly simple Microblaze-based system, just one core,
> >> opb-UART, BRAM, opb-timer and opb-intc. I wrote a small program using
> >> the xilkernel-OS which creates two threads printing a thread-specific
> >> number and the current clock_ticks. The code is given below. I expect
> >> the program to print each second a message of one thread, but that
> >> doesn't work.
> >>
> >> When executing the program both threads seem to enter the code fragment
> >> locked by the mutex nearly at the same time as can be seen by the
> >> printed clock_ticks.
> >> The mutex is declared static and initialized in the static thread
> >> created by xilkernel_main and before creating the "Hello world"-threads.
> >>
> >> <--------------------------->
> >> void thread_func(int number)
> >> {
> >> while (1)
> >> {
> >> pthread_mutex_lock(&print_mutex);
> >> sleep(500);
> >> xil_printf("Ticks = %d. Thread %d says: Hello world!\r\n",
> >> xget_clock_ticks(), number);
> >> sleep(500);
> >> pthread_mutex_unlock(&print_mutex);
> >> }
> >> }
> >> <--------------------------->
> >>
> >> Output via UART:
> >> Ticks = 362. Thread 1 says: Hello world!
> >> Ticks = 365. Thread 2 says: Hello world!
> >> Ticks = 464. Thread 1 says: Hello world!
> >> Ticks = 468. Thread 2 says: Hello world!
> >>
> >>
> >> Regards,
> >>
> >> Andreas
> >
> > hm, I think it each thread should print 1 message once a second
> > and that is what you see as well, so everything is working?
>
> No. As the sleeping is done while the mutex is locked each thread should
> print its message every two seconds. As one tick is approximately 10 ms
> the message of thread 2 is printed 30 ms after the message of thread 1.
> So there must be something wrong.
>
> Regards,
> Andreas
ok, if you say so :)
for me it wasnt so obvious that obtaining mutex lock on 'print_mutex'
will disable all threads from executing!
the 30 milliseconds seems to me also correct as this the time it takes
to send your hello ... over 9600 baud UART
Antti
Article: 108501On 11 Sep 2006 12:58:57 -0700, "kits59@gmail.com" <kits59@gmail.com> wrote: >Hello, > >Recently, I have been trying to simulate my system to verify that the >pieces are working correctly in my EDK project. In order to do this, I >need to use the SmartModel simulation tools for ModelSim 6.1e. I've >read through all of Xilinx's documentation and have set up the >modelsim.ini file correctly, but when I run the simulation, everything >hangs. There are no calls to the BRAM to fetch code for execution. > >The only thing I get that might be a part of the problem is the >following warnings: > ># ** Warning (SmartModel): ># Model is being requested to run at a finer resolution than >necessary. This is not a problem. 1ns resolution is too coarse for SmartModel simulation (and will not work) - 1ps is "too fine" but does work. I haven't tried 100ps or 10ps but suspect one of these is the correc answer. Something else must be the problem : check clocks, resets, is your bRAM mapped to cover the boot address (FFFFFFFC for the PPC405), there are no "Warning: unbound component" messages when ModelSim loads the design etc? - BrianArticle: 108502
Antti schrieb: > Andreas Hofmann schrieb: > >> Antti schrieb: >>> hm, I think it each thread should print 1 message once a second >>> and that is what you see as well, so everything is working? >> No. As the sleeping is done while the mutex is locked each thread should >> print its message every two seconds. As one tick is approximately 10 ms >> the message of thread 2 is printed 30 ms after the message of thread 1. >> So there must be something wrong. >> >> Regards, >> Andreas > > ok, if you say so :) > > for me it wasnt so obvious that obtaining mutex lock on 'print_mutex' > will disable all threads from executing! The other threads should be blocked because sleep() is called while the mutex is held by the sleeping thread. Admittedly my code immediately tries to lock the mutex after releasing it so the other threads may have no chance to execute their lock request. This seems to cause the problems because after enabling yield()-support and calling yield() after pthread_mutex_unlock() solves the problem. The program does now behave as expected. However, i do not fully understand what the kernel is doing when yield() is missing. Shouldn't the other threads, which do not hold the lock, starve while one of the thread locks the mutex over and over again? On the other hand, the Xilinx manual clearly states that when pthread_mutex_unlock() is called "the thread that is at the head of the mutex wait queue is unblocked and allowed to lock the mutex.". Thus calling or omiting yield() shouldn't make any difference. Regards, AndreasArticle: 108503
If you can infer the brams from a constant as shown earlier, it will simulate much faster than instantiated BRAMS. Also, the code would be portable to other architectures/vendors. Andy David Ashley wrote: > Ben Jackson wrote: > > On 2006-09-11, David Ashley <dash@nowhere.net.dont.email.me> wrote: > > > >>I want to create a 1152 by 6 bit rom and I want to use > >>a bram. It can be clocked or not clocked, but I'd prefer > >>not clocked. Can someone point me to a template? > > > > > > There's a whole PDF of them called "xst.pdf" which you can google. > > > > Thank you very much! That's what I was after. > > Well I'll be busy reading for a while... > > -Dave > > -- > David Ashley http://www.xdr.com/dash > Embedded linux, device drivers, system architectureArticle: 108504
skyworld schrieb: > Hi Ray & Kolja, > thanks for your reply. The advice is very helpful, but the question is > that the code is for ASIC design and is frozen. I just migate the code > to FPGA to check its function. So do you have any suggestion on how to > setup constraints? something like DC do in ASIC design? thanks Usually ´the actual performance of the design can not be improved much compared to the results optained by a simple clock cycle constraint. However, often a static timing anaylsis reports an overly pessimistic timing. You can get get better and more realistic values if you specify false paths and multi cycle constraints to relax the timing budget. You can perfom the modifications that I suggested and use an equivalnce checker to proove that you did not change the behaviour of the circuit. That is a risk free approach for a frozen desing. The particular transformation that I described also reduces ASIC circuit area and power consumption. Kolja SulimmaArticle: 108505
It's been a long time since we've used 4000 series parts here, but we have had a similar issue with Virtex (original) parts. It turns out the bad lots were counterfeit. If you got these parts from a franchised Xilinx distributor, your parts are most likely not counterfeit. In that case I would suggest attempting to return them and to open a web case with Xilinx as well. However if you got them through a part broker, which is common for older parts like these, it is possible that they are counterfeit. In the case of the counterfeit Virtex parts, the actual parts were marked with the Xilinx part number and logo, but the chips inside had no resemblance at all to the part marked, and in fact caused a direct short from +3.3V to ground on our boards. Good Luck, Gabor Jacques GENIN wrote: > HI, > > I experience configuration problems with XC4010E parts. > I configure them in slave serial mode : M0,M1,M2 = Z. > Configuration pins (M0-2) do not polarize to VCC as they > should because of their internal pull-ups, so parts enter > configuration mode incompatible with my design. > If I put external pull-ups, those pins polarize correctly > and the configuration process seems good. Though, in this > case, the operation of the devices is wrong or unpredictable. > My design does work correctly with 100s of parts with > external pull-ups or not. I just encountered this behavior > with all parts of two shipments. > Did any one get similar behavior ? > Any help or infomation welcome. > > JAGArticle: 108506
David Ashley schrieb: > Anonymous wrote: > > I have a xilinx soc that is running 2.4 of the PPC linux fine. To run 2.6 is > > it just a matter of copying the arch directory over to the 2.6 tree and > > compiling? (Assuming I keep the configuration options the same.) > > > > Thanks, > > Clark > > If you're starting from scratch I'd strongly recommend going with > a 2.6 kernel. 2.6 is very easy to get a serial port driver working, which > is crucial for debug output while bringing up the kernel. > Google will bring up some step by step instructions for doing this. > > The xilinx free uart-lite core is easy to get working. I brought up > 2.6 on a virtex-2 pro with the embedded PPC cores. u-boot boots > from a small bootloader embedded in one of the BRAMS, which > chains to a NAND flash, which contained u-boot. Finally u-boot > read out linux-2.6 from a different area of the NAND flash. > > I submitted a patch to the u-boot group bringing up u-boot on > the Memec Design FF1152 board some months ago, I doubt if it > has been included in the main source tree of u-boot though. > That included support for the uart lite. Once you've got u-boot > linux gets easy to bring up. If you look at the u-boot archive you > can find my post of the patch. > > Why 2.6? It's the future, man. If you pick 2.4 someday you'll > have to upgrade anyway. Pick the latest first. > > To answer your specific question, code from 2.4 does not just > drop in to 2.6. There are lots of little differences. You can recognize > the same basic code flow from a driver for 2.4 vs 2.6, but a lot of > the low level details are tweaked. It's fairly easy to adapt 2.4 code > to 2.6 code though. > > Xilinx has ethernet cores. I haven't found an out of the box > linux driver, 2.4 or 2.6, for any of Xilinx's cores. u-boot supports > the xilinx ethernet cores. Montevista has drivers for xilinx cores, > but presumably you'd need to pay for their linux version. > > BTW I wasn't able to compile 2.6 under the windows EDK 8.1 > cygwin environment. The build process complains that the > versions of binutils and the compiler don't match, or something, > and that either one or the other has to be upgraded or downgraded. > This was very frustrating, I spent a lot of time trying to get a > working setup, without success. > > In the end I just built linux-2.6 from a linux host and stopped > trying to build software under windows. > > Finally one more note. I found it pointless to use Xilinx's source > code in any form, or their EDK, for the software side of things. > I was always struggling with their includes + IDE + point and > click interface. I invested the time in getting a linux build > environment up where I could build the software side under > linux, and export the ELF executables over to the windows box > which would then integrate into the FPGA bitfile. Once I did > that development went *fast*. Xilinx software is a nest of > fishhooks -- try to get one thing, and it includes more, and that > includes more...pretty soon your 100 byte bootloader doesn't > fit into the 16K bytes you've allocated out of BRAMs for the > PPC init code at FFFFC000... > > -Dave > > -- > David Ashley http://www.xdr.com/dash > Embedded linux, device drivers, system architecture David, would you please please consider zipping all the stuff that is needed to get ppc linux on the memec board running and uploading it? I do have the same board so I could hopefully get a faster start. Sure if there is anything I can offer in return please ask. AnttiArticle: 108507
Hi, I would like to configure a spartan-3 FPGA with an 5V CMOS microcontroller. I have read xilinx database answer regarding how to make 3.3V I/O input pins 5V tolerant with a serial resistor (300Ohm). 1) Can also the confg. dedicated pins made 5V tolerant through a serial resistor although they are powered from 2.5V? (I calculated this an I came to Rser=3D220OHM) 2) The VIH of my microcontroller is 3V, that of spartan-3 I/O's is (VCCO=3D3.3V) is 2.9V. Do I need level-shifters to drive my =B5C? If yes, what IC's would you recommend? Thank you in advance, JJArticle: 108508
Daniel S. wrote: > Weng Tianxiang wrote: > > Daniel S. wrote: > >> David Ashley wrote: > >> Since routing multiple 32+bits buses consumes a fair amount of routing > >> and control logic which needs tweaking whenever the design changes, I > >> have been considering ring buses for future designs. As long as latency > >> is not a primary issue, the ring-bus can also be used for data > >> streaming, with the memory controller simply being one more possible > >> target/initiator node. > >> > >> Using dual ring buses (clockwise + counter-clockwise) to link critical > >> nodes can take care of most latency concerns by improving proximity. For > >> large and extremely intensive applications like GPUs, the memory > >> controller can have multiple ring bus taps to further increase bandwidth > >> and reduce latency - look at ATI's X1600 GPUs. > >> > >> Ring buses are great in ASICs since they have no a-priori routing > >> constraints, I wonder how well this would apply to FPGAs since these are > >> optimized for linear left-to-right data paths, give or take a few > >> rows/columns. (I did some preliminary work on this and the partial > >> prototype reached 240MHz on V4LX25-10, limited mostly by routing and 4:1 > >> muxes IIRC.) > > > > Hi Daniel, > > Here is my suggestion. > > For example, there are 5 components which have access to DDR controller > > module. > > What I would like to do is: > > 1. Each of 5 components has an output buffer shared by DDR controller > > module; > > 2. DDR controller module has an output bus shared by all 5 components > > as their input bus. > > > > Each data has an additional bit to indicate if it is a data or a > > command. > > If it is a command, it indicates which the output bus is targeting at. > > If it is a data, the data belongs to the targeted component. > > > > Output data streams look like this: > > Command; > > data; > > ... > > data; > > Command; > > data; > > ... > > data; > > > > In the command data, you may add any information you like. > > The best benefit of this scheme is it has no delays and no penalty in > > performance, and it has minimum number of buses. > > > > I don't see ring bus has any benefits over my scheme. > > > > In ring situation, you must have (N+1)*2 buses for N >= 2. In my > > scheme, it must have N+1 buses, where N is the number of components, > > excluding DDR controller module. > > > > Weng > > In a basic ring, there needs to be only N segments to create a closed > loop with N nodes, memory-controller included. Double that for a fully > doubly-linked bus. > > Why use a ring bus? > - Nearly immune to wire delays since each node inserts bus pipelining > FFs with distributed buffer control (big plus for ASICs) > - Low signal count (all things being relative) memory controller: > - 36bits input (muxed command/address/data/etc.) > - 36bits output (muxed command/address/data/etc.) > - Same interface regardless of how many memory clients are on the bus > - Can double as a general-purpose modular interconnect, this can be > useful for node-to-node burst transfers like DMA > - Bandwidth and latency can be tailored by shuffling components, > inserting extra memory controller taps or adding rings as necessary > - Basic arbitration is provided for free by node ordering > > The only major down-side to ring buses is worst-case latency. Not much > of an issue for me since my primary interest is video > processing/streaming - I can simply preload one line ahead and pretty > much forget about latency. > > Flexibility, scalability and routability are what makes ring buses so > popular in modern large-scale, high-bandwidth ASICs and systems. It is > all a matter of trading some up-front complexity and latency for > long-term gain. > > Since high-speed parallel buses end up needing pipelining to meet > high-speed timings, the complexity and area delta between multiple > parallel buses and ring-bus topologies is shrinking. > > -- > Daniel Sauvageau > moc.xortam@egavuasd > Matrox Graphics Inc. > 1155 St-Regis, Dorval, Qc, Canada > 514-822-6000 Hi Daniel, It is very interesting to learn there is a ring bus structure over there. "Flexibility, scalability and routability are what makes ring buses so popular in modern large-scale, high-bandwidth ASICs and systems" Can you please me some reference papers about ring bus applications in ASIC or FPGA? Normally what a designer is concerns most about is data latency in a bus structure Thank you. WengArticle: 108509
Gabor a écrit : > It's been a long time since we've used 4000 series parts here, > but we have had a similar issue with Virtex (original) parts. It > turns out the bad lots were counterfeit. If you got these parts > from a franchised Xilinx distributor, your parts are most likely > not counterfeit. In that case I would suggest attempting to > return them and to open a web case with Xilinx as well. > > However if you got them through a part > broker, which is common for older parts like these, it is > possible that they are counterfeit. In the case of the > counterfeit Virtex parts, the actual parts were marked > with the Xilinx part number and logo, but the chips inside > had no resemblance at all to the part marked, and in fact > caused a direct short from +3.3V to ground on our boards. > > Good Luck, > Gabor > Effectively, I got those parts from a broker. I do not think they are counterfeit because they have a part of the behaviour I expect from "good" components. They do not seem to be dumb stones in packages. Anyway, I'm OK : when buying obsolete parts, one must be more and more carefull ! Thanks, anyhow JacquesArticle: 108510
Hi,
We are designing a linear phase FIR filter. Several Cmults are included
in the FIR filter as multipliers. All the coefficients are linear. However,
we are not sure how to import the coefficients from the mask. For example,
from the FDA tool, we can easily export the fixed point coefficients of the
FIR filter to a vector A. We can manually input the coefficients from A to
indivisual Cmults. I am wondering if there is an automatic way to import all
the coefficients.
Any suggestions?
Kuan
Article: 108511skyworld wrote: > Hi Ray & Kolja, > thanks for your reply. The advice is very helpful, but the question is > that the code is for ASIC design and is frozen. I just migate the code > to FPGA to check its function. So do you have any suggestion on how to > setup constraints? something like DC do in ASIC design? thanks > If you are just checking functionality, why are you concerned about timing? Reduce the clock rate and check the functionality, if that is what you intend to do. But you must be concerned about clock distribution (use only global clocks!) otherwise you invite ugly hold-time issues. Peter Alfke, XilinxArticle: 108512
Brian Drummond wrote: > On 11 Sep 2006 12:58:57 -0700, "kits59@gmail.com" <kits59@gmail.com> > wrote: > > >Hello, > > > >Recently, I have been trying to simulate my system to verify that the > >pieces are working correctly in my EDK project. In order to do this, I > >need to use the SmartModel simulation tools for ModelSim 6.1e. I've > >read through all of Xilinx's documentation and have set up the > >modelsim.ini file correctly, but when I run the simulation, everything > >hangs. There are no calls to the BRAM to fetch code for execution. > > > >The only thing I get that might be a part of the problem is the > >following warnings: > > > ># ** Warning (SmartModel): > ># Model is being requested to run at a finer resolution than > >necessary. > > This is not a problem. 1ns resolution is too coarse for SmartModel > simulation (and will not work) - 1ps is "too fine" but does work. I > haven't tried 100ps or 10ps but suspect one of these is the correc > answer. > > Something else must be the problem : check clocks, resets, is your bRAM > mapped to cover the boot address (FFFFFFFC for the PPC405), there are no > "Warning: unbound component" messages when ModelSim loads the design > etc? > > - Brian The funny thing that I should probably state is that the entire system was simulating perfectly fine under EDK 7.2. The bRAM is mapped correctly so that the starting values are where they expect them to be. I haven't tried working with 10ps or 100ps, so I'll try those and report in a little while.Article: 108513
jidan1@hotmail.com wrote: > Hi, > > I would like to configure a spartan-3 FPGA with an 5V CMOS > microcontroller. I have read xilinx database answer regarding how to > make 3.3V I/O input pins 5V tolerant with a serial resistor (300Ohm). > > 1) Can also the confg. dedicated pins made 5V tolerant through a serial > resistor although they are powered from 2.5V? (I calculated this an I > came to Rser=3D220OHM) > 2) The VIH of my microcontroller is 3V, that of spartan-3 I/O's is > (VCCO=3D3.3V) is 2.9V. Do I need level-shifters to drive my =B5C? If yes, > what IC's would you recommend? > >Regarding 1: I would use 1 kilohm. No need to push more current than necessary. Regarding 2: You quote worst-case numbers that assum lowest Vcc on the FPGA and higest possible Vcc on the uP. Keep the FPGA fed with at least 3.2 V, and you will see that same voltage on the output (this is CMOS !), and keep the uP Vcc slightly below 5V. But you will not have much noise immunity. Peter AlfkeArticle: 108514
Hello funkrhytm, On Mon, Sep 11, 2006 at 12:10:38PM -0700, funkrhythm wrote: > are you sure you have all the pin assignments/connections between > plb_temac and hard_temac and such set up properly for the board ? Absolutely not ;-). Thanks for your information. (And for the other mails, too). I'll be away some days, but I hope it will start working next week. -- GPG-Key 1024D/E32C4F4B | www.gnupg.org | http://enigmail.mozdev.org Fingerprint = 9C03 86B5 CA59 F7A3 D976 AD2C 02D6 ED21 E32C 4F4B Mit freundlichen Gruessen | Kun afablaj salutoj (www.esperanto.org) May the tux be with you. :wq 73Article: 108515
jidan, Peter makes a good point: if the resistance is too low, then you are injecting current into the 2.5 V supply, and it may begin to drift up, and out of regulation. One way to avoid that, and to avoid any rail supply being driven above its intended output, is to balance the injected current with a simple resistor across the power supply, present all the time. So, if you think you will inject 100 mA worst case into the 2.5V rail, then plan on having a load of at least 100 mA on the 2.5 volt supply. If the 2.5 volt supply has a minimum normal load of 50 mA, then you will need an additional 50 mA load, just in case. 2.5V/.05=50 ohms (51 ohms, nearest 5% value). All this because regulators are good at regulating a load, but incapable of regulating when you source current into there output terminal. Austin Peter Alfke wrote: > jidan1@hotmail.com wrote: >> Hi, >> >> I would like to configure a spartan-3 FPGA with an 5V CMOS >> microcontroller. I have read xilinx database answer regarding how to >> make 3.3V I/O input pins 5V tolerant with a serial resistor (300Ohm). >> >> 1) Can also the confg. dedicated pins made 5V tolerant through a serial >> resistor although they are powered from 2.5V? (I calculated this an I >> came to Rser=220OHM) >> 2) The VIH of my microcontroller is 3V, that of spartan-3 I/O's is >> (VCCO=3.3V) is 2.9V. Do I need level-shifters to drive my µC? If yes, >> what IC's would you recommend? >> >> Regarding 1: > I would use 1 kilohm. No need to push more current than necessary. > Regarding 2: > You quote worst-case numbers that assum lowest Vcc on the FPGA and > higest possible Vcc on the uP. > Keep the FPGA fed with at least 3.2 V, and you will see that same > voltage on the output (this is CMOS !), and keep the uP Vcc slightly > below 5V. > But you will not have much noise immunity. > Peter Alfke >Article: 108516
KJ wrote: > <james..yahoo.ca> wrote: > > the post-map stage fails its simulation so badly > > > I certainly suspect all the removed > > "redundant logic" that the mapper is reporting. > But you have no basis for that suspicion. It might be the case that the > synthesis process has a bug but you need to prove it.....and then open a > service request on the company that has the bug in it. My point is don't > let your objectivity be clouded by what you suspect, debug and prove. I do have basis, as I wrote previously: using the "keep" statements removed some lines of removed "redundant" logic and dramatically improved success of the post-map simulation. I would indeed, however, like to avoid using this as a crutch and do it properly as you indicate. I would like to find out the correct way to indicate in the VHDL, by the way I write the VHDL, that the logic is not redundant. > > > But how to indicate it > > is not > > really redundant, without using "keep" and "save" statements > > everywhere? > And this is where you start spinning your wheels (in my opinion). Instead > of simply debugging the post-map sim to the source of the discrepancy you're > trying things based on a suspicion that is not proven. Let's say for the > sake of argument that your suspicion is wrong about the removal of redundant > logic and that the problem is a timing issue with your testbench instead. > That would mean that every minute you spend chasing 'keep' and 'saves' etc. > was wasted time. I'm not really arguing for using those crutches; I'm seriously asking what to do so that I don't need them. > > > I > > can't even complain that all my signals are connected (they > > are), because that's not the problem: the mapper is not removing > > "unused logic". > > > This will sound like a dumb question on my part but what is the distinction > in your mind between 'redundant logic' and 'unused logic'? The reason for > my confusion at this point would be because you say the 'redundant' stuff is > getting removed and yet there is no 'unused' logic getting removed. If by > 'redundant' you mean the classical Boolean Logic 101 definition where you > add redundant logic to act as 'cover' terms in your Karnaugh map to avoid > race conditions then that is the most likely cause of your problems. Is > this the type of logic that you are trying to 'keep' but is being mapped > away as an 'optomization'? If it is, then the rest of this post probably > doesn't apply and we can discuss this point further, but if it is not then > keep on reading. The "redundant" and "unused" logic terms I am copying from the mapper report and Xilinx documentation. The mapper report (see my first post) says "redundant" logic is being removed, not "unused logic". >From my reading of the Xilinx manuals I understand that "unused logic" means logic that is not connected to anything, so it can be removed (this latter is not what is happening to me). However, I haven't found anything in the manuals that explains what "redundant logic" is or how to write the code to avoid it. I have a lot of identical ROMs that I use to do parallel processing; those were being removed in the synthesis and translate step due to not having clocks on them. So my mind is pretty much a blank as to what is meant by "redundant" logic, other than the common meaning that it is repetitive -- but it isn't really, of course, because I'm using them simultaneously for different data. > > One other source of 'optomization' is that an output of some entity is not > really used. The logic for equation 'x' happens to reduce down to always > being 'false'. This means that everything downstream of 'x' that depends on > 'x' being true can never happen so it can be optomized away. It's not the > fault of the optomizer removing redundant logic that's the way the original > is coded. You probably already realize this but thought a quick > 'Optomization 101' wouldn't hurt....but I also don't think focusing on what > is being optomized is away is the way you need to go on this one (which is > the reason on my first post I questioned you "Why..."). > > What you need to do is to simulate the post-map VHDL file and trace it back > to why output signal 'x' at time t is set to '0' but when you use your > original code it is '1'. Use the sim results from using your original code > as your guide for what 'should' happen and the post-map VHDL simulation for > what is actually happen and debug the problem. I agree that finding out what is going on is the best approach. Do you have any debugging tips other than comparing the simulation results in detail and seeing what logic calculations must be getting removed? > > It could be that > - There is some bug in the translation tool > - Could be some setting in your build process > - Could be timing related (i.e. your testbench is violating the setup/hold > time requirements for the post-map model) > - Probably other things too > > In any case, treat the fully post-map model as something to debug and find > out the reason for the discrepancy and go from there. Thank you very much for your input. I really appreciate the time you are spending to try to help me. Best regards, -JamesArticle: 108517
Hi David, I just finished an 8 by 8 bit font for hex nibble outputs, 0 to F. I did this for a Xilinx Virtex4 SX35 ML402 dev board in VHDL. The code below might give you some ideas about how to proceed. You can see the font better if you replace the 0s with periods, and back again, when you are ready to synthesize. Brad Smallridge Ai Vision library IEEE; use IEEE.STD_LOGIC_1164.ALL; library UNISIM; use UNISIM.VComponents.all; entity vga_font is port ( clk : in std_logic; rst : in std_logic; addr : in std_logic_vector(14 downto 0); q : out std_logic ); end vga_font; architecture behavioral of vga_font is type init_array_type is array(natural range <>) of bit_vector(7 downto 0); constant vga_font_data : init_array_type :=( "00000000", "00111000", "01111100", "11000110", "11000110", "11000110", "01111100", "00111000", "00000000", "00011000", "00111000", "00011000", "00011000", "00011000", "00011000", "00111100", "00000000", "01111000", "11001100", "00011000", "00110000", "01100000", "11000000", "11111110", "00000000", "01111100", "00000110", "00000110", "00011100", "00000110", "00000110", "01111100", "00000000", "11001100", "11001100", "11001100", "01111110", "00001100", "00001100", "00001100", "00000000", "11111110", "11000000", "11000000", "01111000", "00011100", "00001110", "11111100", "00000000", "00001100", "00011000", "00110000", "01111100", "11000110", "01100110", "00111000", "00000000", "11111110", "00000110", "00001100", "00011000", "00110000", "01100000", "11000000", "00000000", "00111000", "11000110", "11000110", "01111100", "11000110", "11000110", "00111000", "00000000", "00111000", "11000110", "11000110", "00111100", "00011000", "00110000", "01100000", "00000000", "00111000", "01101100", "01101100", "01111100", "11000110", "11000110", "11000110", "00000000", "11111100", "11000110", "11000110", "11111100", "11000110", "11000110", "11111100", "00000000", "00111100", "11000110", "11000000", "11000000", "11000000", "11000110", "00111100", "00000000", "11111000", "11001100", "11000110", "11000110", "11000110", "11001100", "11111000", "00000000", "11111110", "11000000", "11000000", "11110000", "11000000", "11000000", "11111110", "00000000", "11111110", "11000000", "11000000", "11111000", "11000000", "11000000", "11000000", X"00",X"FF" -- also does this format ); function stuff_it ( init_array : init_array_type; init_xx : integer ) return bit_vector is variable result : bit_vector(255 downto 0); variable i : integer ; variable j : integer ; variable temp : bit_vector(7 downto 0); begin result := X"0000000000000000000000000000000000000000000000000000000000000000"; i := 0 ; j := 32*init_xx ; while( (j < init_array'length) and (i<256) ) loop -- result( (i+7) downto (i) ) := init_array(j) ; temp := init_array(j); -- mirror bit vector result(i+7) := temp(0); result(i+6) := temp(1); result(i+5) := temp(2); result(i+4) := temp(3); result(i+3) := temp(4); result(i+2) := temp(5); result(i+1) := temp(6); result(i) := temp(7); i := i + 8 ; j := j + 1 ; end loop; return result; end function stuff_it; signal dob : std_logic_vector(31 downto 0); begin RAMB16_1 : RAMB16 generic map ( DOA_REG => 0, -- Optional output registers on the A port (0 or 1) DOB_REG => 1, -- Optional output registers on the B port (0 or 1) INIT_A => X"000000000", -- Initial values on A output port INIT_B => X"000000000", -- Initial values on B output port INVERT_CLK_DOA_REG => FALSE, -- Invert clock on A port output registers (TRUE or FALSE) INVERT_CLK_DOB_REG => FALSE, -- Invert clock on B port output registers (TRUE or FALSE) RAM_EXTENSION_A => "NONE", -- "UPPER", "LOWER" or "NONE" when cascaded RAM_EXTENSION_B => "NONE", -- "UPPER", "LOWER" or "NONE" when cascaded READ_WIDTH_A => 9, -- Valid values are 1,2,4,9,18 or 36 READ_WIDTH_B => 1, -- Valid values are 1,2,4,9,18 or 36 SIM_COLLISION_CHECK => "ALL", -- "ALL", "WARNING_ONLY", "GENERATE_X_ONLY" or "NONE" SRVAL_A => X"000000000", -- Port A ouput value upon SSR assertion SRVAL_B => X"000000000", -- Port B ouput value upon SSR assertion WRITE_MODE_A => "READ_FIRST", -- WRITE_FIRST, READ_FIRST or NO_CHANGE WRITE_MODE_B => "READ_FIRST", -- WRITE_FIRST, READ_FIRST or NO_CHANGE WRITE_WIDTH_A => 9, -- Valid values are 1,2,4,9,18 or 36 WRITE_WIDTH_B => 9, -- Valid values are 1,2,4,9,18 or 36 INIT_00 => stuff_it(vga_font_data,16#00#), INIT_01 => stuff_it(vga_font_data,16#01#), INIT_02 => stuff_it(vga_font_data,16#02#), INIT_03 => stuff_it(vga_font_data,16#03#), INIT_04 => stuff_it(vga_font_data,16#04#), INIT_05 => stuff_it(vga_font_data,16#05#), INIT_06 => stuff_it(vga_font_data,16#06#), INIT_07 => stuff_it(vga_font_data,16#07#), INIT_08 => stuff_it(vga_font_data,16#08#), INIT_09 => stuff_it(vga_font_data,16#09#), INIT_0A => stuff_it(vga_font_data,16#0A#), INIT_0B => stuff_it(vga_font_data,16#0B#), INIT_0C => stuff_it(vga_font_data,16#0C#), INIT_0D => stuff_it(vga_font_data,16#0D#), INIT_0E => stuff_it(vga_font_data,16#0E#), INIT_0F => stuff_it(vga_font_data,16#0F#), INIT_10 => stuff_it(vga_font_data,16#10#), INIT_11 => stuff_it(vga_font_data,16#11#), INIT_12 => stuff_it(vga_font_data,16#12#), INIT_13 => stuff_it(vga_font_data,16#13#), INIT_14 => stuff_it(vga_font_data,16#14#), INIT_15 => stuff_it(vga_font_data,16#15#), INIT_16 => stuff_it(vga_font_data,16#16#), INIT_17 => stuff_it(vga_font_data,16#17#), INIT_18 => stuff_it(vga_font_data,16#18#), INIT_19 => stuff_it(vga_font_data,16#19#), INIT_1A => stuff_it(vga_font_data,16#1A#), INIT_1B => stuff_it(vga_font_data,16#1B#), INIT_1C => stuff_it(vga_font_data,16#1C#), INIT_1D => stuff_it(vga_font_data,16#1D#), INIT_1E => stuff_it(vga_font_data,16#1E#), INIT_1F => stuff_it(vga_font_data,16#1F#), INIT_20 => stuff_it(vga_font_data,16#20#), INIT_21 => stuff_it(vga_font_data,16#21#), INIT_22 => stuff_it(vga_font_data,16#22#), INIT_23 => stuff_it(vga_font_data,16#23#), INIT_24 => stuff_it(vga_font_data,16#24#), INIT_25 => stuff_it(vga_font_data,16#25#), INIT_26 => stuff_it(vga_font_data,16#26#), INIT_27 => stuff_it(vga_font_data,16#27#), INIT_28 => stuff_it(vga_font_data,16#28#), INIT_29 => stuff_it(vga_font_data,16#29#), INIT_2A => stuff_it(vga_font_data,16#2A#), INIT_2B => stuff_it(vga_font_data,16#2B#), INIT_2C => stuff_it(vga_font_data,16#2C#), INIT_2D => stuff_it(vga_font_data,16#2D#), INIT_2E => stuff_it(vga_font_data,16#2E#), INIT_2F => stuff_it(vga_font_data,16#2F#), INIT_30 => stuff_it(vga_font_data,16#30#), INIT_31 => stuff_it(vga_font_data,16#31#), INIT_32 => stuff_it(vga_font_data,16#32#), INIT_33 => stuff_it(vga_font_data,16#33#), INIT_34 => stuff_it(vga_font_data,16#34#), INIT_35 => stuff_it(vga_font_data,16#35#), INIT_36 => stuff_it(vga_font_data,16#36#), INIT_37 => stuff_it(vga_font_data,16#37#), INIT_38 => stuff_it(vga_font_data,16#38#), INIT_39 => stuff_it(vga_font_data,16#39#), INIT_3A => stuff_it(vga_font_data,16#3A#), INIT_3B => stuff_it(vga_font_data,16#3B#), INIT_3C => stuff_it(vga_font_data,16#3C#), INIT_3D => stuff_it(vga_font_data,16#3D#), INIT_3E => stuff_it(vga_font_data,16#3E#), INIT_3F => stuff_it(vga_font_data,16#3F#), INITP_00 => X"0000000000000000000000000000000000000000000000000000000000000000", INITP_01 => X"0000000000000000000000000000000000000000000000000000000000000000", INITP_02 => X"0000000000000000000000000000000000000000000000000000000000000000", INITP_03 => X"0000000000000000000000000000000000000000000000000000000000000000", INITP_04 => X"0000000000000000000000000000000000000000000000000000000000000000", INITP_05 => X"0000000000000000000000000000000000000000000000000000000000000000", INITP_06 => X"0000000000000000000000000000000000000000000000000000000000000000", INITP_07 => X"0000000000000000000000000000000000000000000000000000000000000000") port map ( CASCADEOUTA => open, -- 1-bit cascade output CASCADEOUTB => open, -- 1-bit cascade output DOA => open, -- 32-bit A port Data Output DOB => dob, -- 32-bit B port Data Output DOPA => open, -- 4-bit A port Parity Output DOPB => open, -- 4-bit B port Parity Output ADDRA => (others=>'1'), -- 15-bit A port Address Input ADDRB => addr, -- 15-bit B port Address Input CASCADEINA => '0', -- 1-bit cascade A input CASCADEINB => '0', -- 1-bit cascade B input CLKA => '0', -- Port A Clock CLKB => clk, -- Port B Clock DIA => (others=>'1'), -- 32-bit A port Data Input DIB => (others=>'1'), -- 32-bit B port Data Input DIPA => (others=>'1'), -- 4-bit A port parity Input DIPB => (others=>'1'), -- 4-bit B port parity Input ENA => '0', -- 1-bit A port Enable Input ENB => '1', -- 1-bit B port Enable Input REGCEA => '0', -- 1-bit A port register enable input REGCEB => '1', -- 1-bit B port register enable input SSRA => '0', -- 1-bit A port Synchronous Set/Reset Input SSRB => '0', -- 1-bit B port Synchronous Set/Reset Input WEA => (others=>'0'), -- 4-bit A port Write Enable Input WEB => (others=>'0') ); -- 4-bit B port Write Enable Input q <= dob(0); end behavioral; "David Ashley" <dash@nowhere.net.dont.email.me> wrote in message news:DIGdnY0WlLIGaJjYnZ2dnUVZ_tmdnZ2d@adelphia.com... >I want to create a 1152 by 6 bit rom and I want to use > a bram. It can be clocked or not clocked, but I'd prefer > not clocked. Can someone point me to a template? > > Embedded linux, device drivers, system architectureArticle: 108518
Brad Smallridge wrote:
> Hi David,
>
> I just finished an 8 by 8 bit font for hex nibble outputs, 0 to F.
> I did this for a Xilinx Virtex4 SX35 ML402 dev board in VHDL.
> The code below might give you some ideas about how to proceed.
> You can see the font better if you replace the 0s with periods,
> and back again, when you are ready to synthesize.
> ...
> RAMB16_1 : RAMB16
> generic map (
> DOA_REG => 0, -- Optional output registers on the A port (0 or 1)
> DOB_REG => 1, -- Optional output registers on the B port (0 or 1)
> INIT_A => X"000000000", -- Initial values on A output port
> INIT_B => X"000000000", -- Initial values on B output port
> INVERT_CLK_DOA_REG => FALSE, -- Invert clock on A port output registers
> (TRUE or FALSE)
> INVERT_CLK_DOB_REG => FALSE, -- Invert clock on B port output registers
> (TRUE or FALSE)
> RAM_EXTENSION_A => "NONE", -- "UPPER", "LOWER" or "NONE" when cascaded
> RAM_EXTENSION_B => "NONE", -- "UPPER", "LOWER" or "NONE" when cascaded
> READ_WIDTH_A => 9, -- Valid values are 1,2,4,9,18 or 36
> READ_WIDTH_B => 1, -- Valid values are 1,2,4,9,18 or 36
> SIM_COLLISION_CHECK => "ALL", -- "ALL", "WARNING_ONLY", "GENERATE_X_ONLY"
> or "NONE"
> SRVAL_A => X"000000000", -- Port A ouput value upon SSR assertion
> SRVAL_B => X"000000000", -- Port B ouput value upon SSR assertion
> WRITE_MODE_A => "READ_FIRST", -- WRITE_FIRST, READ_FIRST or NO_CHANGE
> WRITE_MODE_B => "READ_FIRST", -- WRITE_FIRST, READ_FIRST or NO_CHANGE
> WRITE_WIDTH_A => 9, -- Valid values are 1,2,4,9,18 or 36
> WRITE_WIDTH_B => 9, -- Valid values are 1,2,4,9,18 or 36
Brad,
Thanks. It looks too specific to xilinx though. When I added a clock
the brams got inferred automatically. See sample below. The
address input would have to be character# * font_row, and
the result is a 6 bit strip for that row.
0 <= character# <= 0x5f --- ascii chars from 0x20 to 0x7f
0 <= font_row <= 11 -- row of font (6x12 font)
-Dave
library IEEE;
use IEEE.STD_LOGIC_1164.ALL;
use ieee.numeric_std.all;
entity fontrom is
port (
clk : in std_logic;
addr : in unsigned ( 10 downto 0);
data : out std_logic_vector ( 5 downto 0)
);
end fontrom;
architecture rtl of fontrom is
type small_rom is array (0 to 1151)
of std_logic_vector(5 downto 0);
constant this_rom : small_rom :=
(
0 => "000000",
1 => "000000",
2 => "000000",
3 => "000000",
4 => "000000",
5 => "000000",
-- font data deleted for brevity, font is 6x12, ascii characters from
0x20 to 0x7f
1145 => "111111",
1146 => "111111",
1147 => "111111",
1148 => "111111",
1149 => "111111",
1150 => "111111",
1151 => "111111",
others => "000000"
);
begin
process(clk)
begin
if clk'event and clk = '1' then
data <= this_rom(to_integer(addr));
end if;
end process;
end architecture rtl;
--
David Ashley http://www.xdr.com/dash
Embedded linux, device drivers, system architecture
Article: 108519
Hello Subroto!
That article did it. I was able to revise my simple project, load it
and got my LED to start flashing. Thanks a lot.
"Subroto Datta" < > wrote in message
news:tQrNg.347$e66.257@newssvr13.news.prodigy.com...
> Hi Jack,
> This post may be useful:
> http://groups.google.com/group/comp.arch.fpga/browse_frm/thread/27cd7423127f3bbb/1fbb4ad5554ab9ca?lnk=st&q=device+and+pin+subroto&rnum=2#1fbb4ad5554ab9ca
>
> It deals with setting up Unused Pins for your projecs to the correct
> value.
>
> Hope this helps,
> Subroto Datta
> Altera Corp.
>
> "Jack Zkcmbcyk" <zkcmbcyk9@hotmail.com> wrote in message
> news:s5qNg.40493$8g4.523646@weber.videotron.net...
>> Hello out there!
>>
>> I have purchased an Altera Nios II Cyclone based (EP1C12F324) evalution
>> kit a while ago and didn't get to work with until recently. At first I
>> was happy to see how quickly I got the board up and running and
>> interacting with my PC through an Ethernet LAN and serving web pages
>> using the uClinux on-board http server.
>>
>> Having had enough of the demo I started developping an application of
>> my own. I first downloaded (via the USB cable connector that provides a
>> USB Blaster interface) a very simple code file to start flashing the
>> LEDs. When that didn't work, I simplified the code to an even simpler
>> test case where only one LED was involved. After that not even working,
>> I started combing through the documentation in search for some clues.
>> This is when I noticed a lot of little discrepencies between the real
>> board and the document set.
>>
>> To this day, I still haven't been able to get a simple LED to flash
>> (not even once). I am getting a bit impatient with the whole thing and
>> might just go back to a Xilinx board that is sitting around my ofice.
>> Before I do that, I would like to know if any one out there has played
>> with this board and might have some hints for me.
>>
>> Thanks in advance for any tid bits.
>>
>> P.S. When I download the code to the board using the Quartus II
>> (6.0sp1), the download program seems all happy and returns with a
>> "SUCCESS" message at the end of the process. The board on the other end
>> always contains the same NiosII implementation running uClinux!!! Could
>> it be that after the JTAG load is complete the FPGA resets and simply
>> reloads the default application from the on-board configuration deice?
>>
>
>
Article: 108520Andreas Hofmann wrote: > The other threads should be blocked because sleep() is called while the > mutex is held by the sleeping thread. > > Admittedly my code immediately tries to lock the mutex after releasing > it so the other threads may have no chance to execute their lock > request. This seems to cause the problems because after enabling > yield()-support and calling yield() after pthread_mutex_unlock() solves > the problem. The program does now behave as expected. > > However, i do not fully understand what the kernel is doing when yield() > is missing. Shouldn't the other threads, which do not hold the lock, > starve while one of the thread locks the mutex over and over again? > > On the other hand, the Xilinx manual clearly states that when > pthread_mutex_unlock() is called "the thread > that is at the head of the mutex wait queue is unblocked and > allowed to lock the mutex.". Thus calling or omiting yield() shouldn't > make any difference. Andreas, Something is wrong. As your code is written there is no way the 2 threads can print out timestamps so close together. It's as if your pthread locking is having no affect at all. Did you init the mutex? Is the mutex residing on some cacheable memory, and the cache hasn't been flushed? Check the details of the mutex itself, there may be limitations. On blackfin dsp mutex locking was based on their test and set instruction, which was flawed -- you had to use external memory otherwise it didn't work. There may be something similiar going on here. -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108521
Weng Tianxiang wrote: > Hi Daniel, > It is very interesting to learn there is a ring bus structure over > there. Weng, It occured to me that your circuit was identical to the ring buffer one. N users each had a fifo going to the DDR. Then there was one stream coming out of the DDR, so it's (N+1) interfaces. But then you said each user needs its own fifo so it can store + forward data from the DDR. So you've got 2N interfaces effectively. The new fifos are just moved into the user's realm and not part of the DDR controller. My point is the same circuitry exists in both cases. You've just exercised some creative accounting :). -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108522
james7uw@yahoo.ca wrote:
> >
> > > But how to indicate it
> > > is not
> > > really redundant, without using "keep" and "save" statements
> > > everywhere?
> > And this is where you start spinning your wheels (in my opinion). Instead
> > of simply debugging the post-map sim to the source of the discrepancy you're
> > trying things based on a suspicion that is not proven. Let's say for the
> > sake of argument that your suspicion is wrong about the removal of redundant
> > logic and that the problem is a timing issue with your testbench instead.
> > That would mean that every minute you spend chasing 'keep' and 'saves' etc.
> > was wasted time.
>
> I'm not really arguing for using those crutches; I'm seriously
> asking what to do so that I don't need them.
Like I said, what you have to do is debug the 'optomized post-map'
simulation model in the simulation environment to find out just exactly
when it differs from the original code and then backtrack through the
logic in the post-map design to find out why that is.
There really are no shortcuts to this process other than the things I
mentioned in earlier posts (like maybe the testbench is 'violating'
timing, use of things other than std_ulogic/std_logic, etc.).
>
> The "redundant" and "unused" logic terms I am copying from the mapper
> report and Xilinx documentation. The mapper report (see my
> first post) says "redundant" logic is being removed, not "unused
> logic".
> >From my reading of the Xilinx manuals I understand that "unused logic"
> means logic that is not connected to anything, so it can be removed
> (this latter is not what is happening to me).
> However, I haven't found anything in the manuals that explains what
> "redundant logic" is or how to write the code to avoid it.
A simple example of the 'redundant' logic that I was asking about is
something that one might decide to put in to avoid race conditions is
the following code which implements a transparent latch (By the way, do
not implement this in real code in an FPGA).
Q <= (en and D) -- #1
or (not(en) and Q) -- #2
or (en and Q); --#3
The point is that #3 is a redundant logic term and any synthesis tool
will be able to recognize this and remove it. If you remember how to
do Karnaugh maps this example is also easy enough to see it for
yourself. If you don't know about Karnaugh maps just take my word on
it that #1 and #2 are 'logically' all you need. Term #3 is something
that you would need to put into any actual implementation because using
only #1 and #2, although they are logically complete have a race
condition when 'en' is switching.
My whole reason for bringing this up was just to rule out the
possibility that this is what you meant by 'redundant'. I didn't think
it was, but just wanted to confirm. Moving on.
> I have a lot
> of identical ROMs that I use to do parallel processing; those were
> being removed in the synthesis and translate step due to not having
> clocks on them.
I don't doubt what you say but I also don't quite understand why ROMs
would be 'removed' either. Maybe all you meant is that is that you
couldn't find specific entities in the post-map VHDL that equated to
the various 'ROMs' that you instantiated in the original code....but
that's OK, a ROM is simply an array of constants, I would expect those
to get rolled right into the logic. I can see where targetting a
particular family might have to use logic blocks instead of embedded
memory to implement what your code says (but could use embedded memory
if you chose to implement a clocked ROM) but that doesn't mean that
that the original unclocked ROM is not synthesizable at all.
> So my mind is pretty much a blank as to what is
> meant by "redundant" logic, other than the common meaning that it
> is repetitive -- but it isn't really, of course, because I'm using them
> simultaneously for different data.
'Redundant' in this context generally means that the fitter found that
you have two equations that are logically equivalent. An example...
d <= a or b or c;
h <= e or f or g;
....
a <= e;
b <= f;
c <= g;
The signal 'h' is redundant since it is logically equivalent to 'd'
since, although the signals appear to be different for calculating 'h',
from a logic perspective they are identical because of the 'a<= e....'
assignments.
>
> I agree that finding out what is going on is the best
> approach. Do you have any debugging tips other than comparing
> the simulation results in detail and seeing what logic calculations
> must be getting removed?
>
None, other the ones listed below and in previous posts. Tweaking the
'no optomize' switches won't get you to the bottom of what ails your
sim. It might just postpone the inevitable when you might find that
your design doesn't work on real hardware.
If the problem is actually in your testbench in how you generate inputs
to your design (i.e. meeting the timing requirements of the post-map
design) then this should be relatively straightforward to fix. In
fact, this is a fairly common reason for why 'post' does not match
'pre' simulation results.
If nothing else it is probably much quicker to verify testbench timing
than to debug back through the post-map design....but that just means
you should look at that first. If that's not the problem then you need
to debug.
> >
> > It could be that
> > - There is some bug in the translation tool
> > - Could be some setting in your build process
> > - Could be timing related (i.e. your testbench is violating the setup/hold
> > time requirements for the post-map model)
> > - Probably other things too
> >
> > In any case, treat the fully post-map model as something to debug and find
> > out the reason for the discrepancy and go from there.
>
> Thank you very much for your input. I really appreciate
> the time you are spending to try to help me.
>
Good luck, not sure I'm helping much.
KJ
Article: 108523james7uw@yahoo.ca wrote: >From my reading of the Xilinx manuals I understand that "unused logic" > means logic that is not connected to anything, so it can be removed > (this latter is not what is happening to me). > However, I haven't found anything in the manuals that explains what > "redundant logic" is or how to write the code to avoid it. I have a lot > of identical ROMs that I use to do parallel processing; those were > being removed in the synthesis and translate step due to not having > clocks on them. So my mind is pretty much a blank as to what is > meant by "redundant" logic, other than the common meaning that it > is repetitive -- but it isn't really, of course, because I'm using them > simultaneously for different data. James, Maybe there are switches to the synthesizer that would allow turning off the optimization? I would tend to agree that looking for bugs in the toolchain might not be the best way to work through this. I haven't been following this thread all along, but one thing occurs to me. I'm new to VHDL and have settled in to an approach where I make little incremental changes, then immediately test and verify something didn't break. That way I can go back and the source of the problem is obvious, because there is only a little bit of code to examine. In your case it's like maybe the sequence is working, change code working, change code working, change code working, change code broken, change code <-- it broke here but you didn't discover it broken, change code broken, change code broken, change code broken <--- you're here It's just a theory. But I've seen this sort of thing before. The most recent change didn't cause the problem and in fact couldn't have caused the problem, but it's not working. Therefore the tools must be broken. Really the problem occured earlier... Sorry to intrude... -Dave -- David Ashley http://www.xdr.com/dash Embedded linux, device drivers, system architectureArticle: 108524
Andreas Hofmann wrote: > On the other hand, the Xilinx manual clearly states that when > pthread_mutex_unlock() is called "the thread > that is at the head of the mutex wait queue is unblocked and > allowed to lock the mutex.". Thus calling or omiting yield() shouldn't > make any difference. Unblocking a thread is not the same as giving it processor time. Assuming there are only two threads, then the unblocked thread will not actually execute unless it has a higher priority than the current thread, or the current thread blocks. If the both threads have equal priority, then the blocked thread will also run if the current thread calls sched_yield(). And if the priorities are equal and the current thread uses the SCHED_RR policy, then the blocked thread will also run when the current thread's time quantum expires. If either thread uses the SCHED_OTHER policy then all bets are off. Likewise, if Xilinx's implementation is not POSIX conforming, then who knows what will happen.
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