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
On May 3, 11:18 am, HansWernerMarsc...@web.de wrote: > You find at the web and in books implementations of processors for FPGA > =B4s and also processors like Picoblaze and Microblaze from firms like > Xilinx. Are there also implementations of processors special designed > for signal processing that realize things like FFT for example ? > > Thanks for help If you're performing signal processing, straight FPGA logic is more suited to this than using the resources to instantiate a general purpose processor with built-in DSP extensions. Since most signal processing applications can be performed in parallel, this can be exactly realized in the FPGA fabric rather than attempted by having "very fast" computational pipelines in a DSP processor. If you are hard pressed on having a GPP, then why not look at DSP co- processors to perform the functions you're looking for: FFT, L/HPF, etc. Depending on the base architecture you start with you have options like using the FSL on the Microblaze to have a low-latency communication interface, or the ports on the Picoblaze. Although, depending on the algorithm(s) you are planning on running it may be difficult to get by with the standard Picoblaze because of its limited instruction memory. -- MikeArticle: 131851
On Sat, 3 May 2008 08:18:33 -0700 (PDT), HansWernerMarschke@web.de wrote: >You find at the web and in books implementations of processors for FPGA >´s and also processors like Picoblaze and Microblaze from firms like >Xilinx. Are there also implementations of processors special designed >for signal processing that realize things like FFT for example ? Yes and no. There are certainly components which realize FFT only, or FIR filter only, etc. But I don't know of any "DSP oriented" CPU blocks. I believe these would typically be larger than Microblaze etc, and typically much slower than a pure FFT component. Therefore they would usually give you the worst of both worlds. The effort spent generating optimal code for such a DSP engine is probably better spent generating optimal hardware to realize the same function; you are likely to gain a lot in performance. (I realize there are probably exceptions to this principle, but my perception is they are relatively small niches). - BrianArticle: 131852
Alain, Yes, that is a neat feature (allow a set or reset with small overhead while still using SRL), however I have seen a thread where it isn't working as intended for some cases. There is a CR filed on it, so we will see if it is a real bug, or a weird corner case (which still needs to get fixed). Automatic use of SRL16(and/or SRL64 in V5) by the synthesis tool is not consistent as third party tools don't always make the many cases where the SRL is advantageous a priority. XST pioneers the use, so we may then show third parties how we did it (and give it to them). AustinArticle: 131853
On May 2, 11:34 pm, "MM" <mb...@yahoo.com> wrote: > I guess Antti is right... Anyway, which version of the tools are you using? 9.2i > What is you microcontroller? Freescale MCF5234 Coldfire > Do you have any external pullups? No. > Do you disconnect the cable when running your player? Yes > There is a number of Answer Records on Xilinx site, which might be relevant to your problem. > e.g.http://www.xilinx.com/support/answers/22255.htm I've looked, but I can't seem to find one that helps... I need to get this working by Friday, so I hope someone has some ideas? Thanks, -BobArticle: 131854
Hi. Does anyone have recommendations for a pcb fab vendor and an assembly vendor ? Preferably the same vendor but ok if not. This is for just a few small boards, 6-8 layers, a couple of FPGAs in bga package. I'm looking for quality 1st & price 2nd. Don't want any bad coonections on some power & gnd balls. Thanks JimArticle: 131855
austin <austin@xilinx.com> wrote: >Alain, > >Yes, that is a neat feature (allow a set or reset with small overhead >while still using SRL), however I have seen a thread where it isn't >working as intended for some cases. There is a CR filed on it, so we >will see if it is a real bug, or a weird corner case (which still needs >to get fixed). > >Automatic use of SRL16(and/or SRL64 in V5) by the synthesis tool is not >consistent as third party tools don't always make the many cases where >the SRL is advantageous a priority. XST pioneers the use, so we may >then show third parties how we did it (and give it to them). Which version of XST supports this? I always infer SRL16 (and similar) from primitives out of lazyness. -- Programmeren in Almere? E-mail naar nico@nctdevpuntnl (punt=.)Article: 131856
Nicolas Matringe wrote: > whygee a =E9crit : >> Don't ask me that, I'm just looking in the trash bin :-) > Yann you'll have to tell me where this is ;-) ok :-) my old f-cpu email address still works ;-P Hint : it's in Paris. btw, i checked my treasure : there are 57 reels of resistors and about 30 of ceramic capacitors. I'm riiich \o/ :-) But i'll have to build a reel holder, with all the wood that i have also found there :-) then i'll have to etch a pair of PCB for the XCV400. > Nicolas ygArticle: 131857
Hi
1) I am having some EDK simulation problems. I am using EDK9.2i with
microblaze 7.
I have attached a peripheral to the FSL bus using EDK's configure
coprocessor and written its corresponding drivers for the peripheral
which has commands like the one below. ie..
#include "mb_interface.h"
....
microblaze_bwrite_fsl(data,0);
I tried generating simulation libraries to test my drivers
interfacing with the attached peripheral. I created a test bench
system_tb which would instantiate system.vhd. In addition, I had also
added the following lines:
configuration system_tb_conf of system_tb is
for all
for all : system use configuration work.system_conf;
end;
end for;
end system_tb_conf;
to ensure that the initialised BRAM by data2mem is picked up correctly
with the command:
vsim -t ps system_tb_conf
. I have also ensured that microblaze + its peripherals do come out of
resets correctly.
however, when I probe the FSL bus from the microblaze processor, only
data from FSL0_M_data has data. The write signals from FSL0_M_write
are never asserted. In addition, no other signals from the microblaze
driving the FSL bus is asserted.
Did I miss out anything? I have set up EDK for simulation before
whilst using EDK9.1i and have done exactly the same things to get the
simulation up and running. However, it just does not seem to work in
this case.
the system I am using is the default base from the xsb provided by
Avnet with the exception to the FSL buses which is required to link to
the peripheral. I am using FSL link 0.
thanks for your help in advance!
Chris
Article: 131858On 2008-05-04, Brian Drummond <brian_drummond@btconnect.com> wrote: > The effort spent generating optimal code for such a DSP engine is probably > better spent generating optimal hardware to realize the same function; you are > likely to gain a lot in performance. > > (I realize there are probably exceptions to this principle, but my perception is > they are relatively small niches). In principle I agree with you, but in practice I can see quite a few advantages to an FPGA optimized DSP processor. Consider for example a video conference application with DVD quality video and audio. You probably want to have custom hardware for most of the video encoding and perhaps decoding as well. However, I don't think there is any need for custom hardware for audio encoding/decoding. But it might make sense to use a specialized DSP processor for that encoding and decoding so that more CPU time is available for other parts of the system (part of the video decoder for example). So in this case, instead of making custom hardware for both video encoding/ decoding and audio encoding/decoding, a generic DSP processor block can be used for many tasks. This will most probably reduce the total logic area and it will certainly reduce the design time of the application. /AndreasArticle: 131859
Hi, It's hard to tell with so little information. Did MicroBlaze get out of reset in the simulation? Did MicroBlaze start to execute code from your application? If MicroBlaze gets to the instruction that writes data to FSL, the only thing stopping it is if the fsl_full flag is asserted. Göran <chrisdekoh@gmail.com> wrote in message news:9ae5b725-6219-4ac9-b5ff-af7ce4d50df8@w1g2000prd.googlegroups.com... > Hi > > 1) I am having some EDK simulation problems. I am using EDK9.2i with > microblaze 7. > I have attached a peripheral to the FSL bus using EDK's configure > coprocessor and written its corresponding drivers for the peripheral > which has commands like the one below. ie.. > > #include "mb_interface.h" > > .... > microblaze_bwrite_fsl(data,0); > > > > I tried generating simulation libraries to test my drivers > interfacing with the attached peripheral. I created a test bench > system_tb which would instantiate system.vhd. In addition, I had also > added the following lines: > > configuration system_tb_conf of system_tb is > for all > for all : system use configuration work.system_conf; > end; > end for; > end system_tb_conf; > > to ensure that the initialised BRAM by data2mem is picked up correctly > with the command: > > vsim -t ps system_tb_conf > > . I have also ensured that microblaze + its peripherals do come out of > resets correctly. > > however, when I probe the FSL bus from the microblaze processor, only > data from FSL0_M_data has data. The write signals from FSL0_M_write > are never asserted. In addition, no other signals from the microblaze > driving the FSL bus is asserted. > > Did I miss out anything? I have set up EDK for simulation before > whilst using EDK9.1i and have done exactly the same things to get the > simulation up and running. However, it just does not seem to work in > this case. > > the system I am using is the default base from the xsb provided by > Avnet with the exception to the FSL buses which is required to link to > the peripheral. I am using FSL link 0. > > > > thanks for your help in advance! > > ChrisArticle: 131860
Bob, (04.05.2008 16:50): >> Do you have any external pullups? > No. Did you check "Drive Done Pin High" in the startup options? AndreasArticle: 131861
On May 5, 10:30 am, Andreas H=F6lscher <andreas.hoelsc...@dsa-ac.de> wrote: > Did you check "Drive Done Pin High" in the startup options? Maybe, but I don't think so. I thought of trying this, but I'm not convinced it has anything to do with it. DONE not going high is just a convenient way to tell if the configuration was successful, as I have it controlling an LED. Furthermore, the configuration is not "taking effect", and the FPGA remains unconfigured. On the other hand, if this "option" is automatically applied by iMPACT when it is doing an actual FPGA configuration, but it is not added to the recorded .svf or .xsvf files, then you may be right. So, I will try it tonight (~8:30 PM EDT), and let you all know. In the meantime, in seems there are a number of potential "gotchas" with various options that may be applied to the bit file generation process. Or to put it another way, I've become quite concerned that I'm missing some critical options that may well be documented somewhere and I messed it, or perhaps something everyone assumes I know when in reality I don't. Can someone who has done this give me a concise list of options they used, or what options are critical, or can point me to documentation on this (other then XAPP058)? Whatever is easy - I'm not asking for anything fancy. Thanks! -BobArticle: 131862
"Bob" <rsg.uClinux@gmail.com> wrote in message news:286aab22-ec7d-4c46-b232-049bd306e451@a23g2000hsc.googlegroups.com... > On May 2, 11:34 pm, "MM" <mb...@yahoo.com> wrote: > >> Do you have any external pullups? > No. I am not sure if this could be your problem, but... normally JTAG signals require pullups. Bitgen can (and probably does) enable them internally, but personally I've never relied upon them and always designed in external resistors... The behaviour with iMPACT might be different because there might be some pullups inside of the programming cable and/or simply the drivers/receivers are different. /MikhailArticle: 131863
> You'll also find that changes (like switching the Nobl SRAM to DRAM as an > example) can be accomodated without having to change *everything*. That has been on my mind because there is a DRAM on my board. Not only will the DRAM require more cycles but perhaps too a varying number of cycles depending on the sequentiality or randomness of the addressing. I have seen controllers on the Xilinx site, but nothing, that talks about several ports, and how the hand shaking is handled. My FAE has said that some multiport examples are availble. Brad Smallridge AiVisionArticle: 131864
On May 1, 8:59 pm, "bjzhan...@gmail.com" <bjzhan...@gmail.com> wrote: > On 5=D4=C21=C8=D5, =CF=C2=CE=E711=CA=B140=B7=D6, ghel...@lycos.com wrote: > > > On May 1, 2:27 am, "bjzhan...@gmail.com" <bjzhan...@gmail.com> wrote: > > > > Hi,everybody,I am a fresher of NIOSII,and in the passed days ,I have > > > been familar with the nios II system,also write some test program > > > about the gpio,timer,uart and can work properly,today I add the flash > > > controoler(CFI),but it doesn't work.And I use the signal tap to watch > > > the wave and the address bus is active but the read,write and cs is > > > always '1',I don't know why,can someone give me some advice and debug > > > methods. > > > Here are two helpful links: > > <http://www.google.com/search?q=3Ddebug+nios> > > <http://www.google.com/search?q=3Dsimulate+nios> > > > Here's something to read while you're trying to figure out how to use > > google's search feature: > > <http://www.altera.com/literature/an/an351.pdf> > > > You really should learn about Google's search feature; it works pretty > > well. And it's free for google-mail users (such as yourself), and the > > rest of the internet. > > > Cheers, > > G. > > Thanks,I have tried all what you say 2 days before and I have no idear > so I refer to Google group for help.Now I know why,Firstly,the flash > chip I use is not support CFI.but the nios II only support CFI > compliant flash.Secondly,because the jtag uart also use jtag ,so if I > use printf function and from the signal tap the signal I watch is > always '1',I remove the printf function and then the signal is active > in the signal tap. NIOS supports many types of NOR flash, and adding a new type is usually a software change in the HAL. If you're trying to use NAND flash, there are application notes for those. You can use a 'traditional' UART instead of the JTAG UART. Several design examples for this on the Altera web site. Keep googleing, G.Article: 131865
Bob wrote: > In the meantime, in seems there are a number of potential "gotchas" > with various options that may be applied to the bit file generation > process. Or to put it another way, I've become quite concerned that > I'm missing some critical options that may well be documented > somewhere and I messed it, or perhaps something everyone assumes I > know when in reality I don't. Can someone who has done this give me a > concise list of options they used, or what options are critical, or > can point me to documentation on this (other then XAPP058)? Whatever > is easy - I'm not asking for anything fancy. > > Thanks! > -Bob > I have used XAPP058 to get a working setup. The only thing I struggled with was getting the DONE pin to go high. I belive the code has two options for the "RUNTEST" SVF instruction (or something like that): one is a delay loop and the other puts out clocks. Make sure you pick the code that puts out the clocks. The delay loop won't work. This was for a Spartan3A FPGA. MDArticle: 131866
The quadrature encoder has been tested and proven to work ( thank you,
Ken Chapman), detecting every transition as a count pulse, never an
accumulated error. The only flaw is a one-pulse backlash. That means,
it does not recognize the first change after a reversal of direction.
You could call it hysteresis, analogous to a +/- 1 count ambiguity,
known to exist in many conversions.
Peter Alfke
Below is the vhdl file, courtesy of my friend Ken Chapman:
----------------------------------------------------------------------------------------------------------------------------------
-- Shaft Encoder
----------------------------------------------------------------------------------------------------------------------------------
--
-- Interface to rotary encoder.
-- Detection of movement and direction.
--
-- The rotary switch contacts are filtered using their offset (one-
hot) style to
-- clean them. Circuit concept by Peter Alfke.
-- Note that the clock rate is fast compared with the switch rate.
--
rotary_filter: process(clk)
begin
if clk'event and clk='1' then
--Synchronise inputs to clock domain using flip-flops in input/
output blocks.
rotary_a_in <= rotary_a;
rotary_b_in <= rotary_b;
--concatinate rotary input signals to form vector for case
construct.
rotary_in <= rotary_b_in & rotary_a_in;
case rotary_in is
when "00" => rotary_q1 <= '0';
rotary_q2 <= rotary_q2;
when "01" => rotary_q1 <= rotary_q1;
rotary_q2 <= '0';
when "10" => rotary_q1 <= rotary_q1;
rotary_q2 <= '1';
when "11" => rotary_q1 <= '1';
rotary_q2 <= rotary_q2;
when others => rotary_q1 <= rotary_q1;
rotary_q2 <= rotary_q2;
end case;
end if;
end process rotary_filter;
--
-- Pipeline the valies of q1 and q2 so that we can detect ANY changes
and determine what changed.
--
-- The detection of any change is considered a rotation event.
--
-- Then the direction of rotation in one direction is indicated
by.....
-- q1 changing from Low to High when q2 is Low
-- or
-- q1 changing from High to Low when q2 is High
-- or
-- q2 changing from Low to High when q1 is High
-- or
-- q2 changing from High to Low when q1 is Low
--
-- Clearly if neither of the above are true then the rotation was in
the opposite direction.
--
shaft_direction: process(clk)
begin
if clk'event and clk='1' then
delay_rotary_q1 <= rotary_q1;
delay_rotary_q2 <= rotary_q2;
rotary_event <= (rotary_q1 xor delay_rotary_q1) or (rotary_q2 xor
delay_rotary_q2);
rotary_right <= ( (not delay_rotary_q1) and rotary_q1 and
(not rotary_q2) )
or ( delay_rotary_q1 and (not rotary_q1)
and rotary_q2 )
or ( (not delay_rotary_q2) and rotary_q2
and rotary_q1 )
or ( delay_rotary_q2 and (not rotary_q2) and
(not rotary_q1) );
end if;
end process shaft_direction;
--
--
-- A simple binary counter is used to record directional change
-- LEFT decrements counter.
-- RIGHT increments counter.
--
position_counter: process(clk)
begin
if clk'event and clk='1' then
if rotary_event = '1' then
if rotary_right = '1' then
rotate_counter <= rotate_counter + 1;
else
rotate_counter <= rotate_counter - 1;
end if;
end if;
end if;
end process position_counter;
--
----------------------------------------------------------------------------------------------------------------------------------
--
--
end Behavioral;
------------------------------------------------------------------------------------------------------------------------------------
--
-- END OF FILE shaft_encoder.vhd
Article: 131867On May 5, 12:13=A0pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> wrote: > > You'll also find that changes (like switching the Nobl SRAM to DRAM as a= n > > example) can be accomodated without having to change *everything*. > > That has been on my mind because there is a DRAM on my board. Not only > will the DRAM require more cycles but perhaps too a varying number of > cycles depending on the sequentiality or randomness of the addressing. > Except for the most special case examples, DRAM access will be a variable delay because of page changes and memory refresh. Trying to design a state machine that is simply trying to *access* memory for some algorithmic purpose would likely result in a difficult to maintain design. Designing a request/acknowledge interface to some other process or entity (in this case the 'other' being a DRAM controller) results in a much easier to maintain design. Using the exact same interface signal functionality whether one is talking to internal FPGA memory, NoBL or SDRAM or SPI results in a design that can be reused, retargeted and improved upon if necessary. Using the same signal naming functionality as an existing documented specification (i.e. Avalon, Wishbone) allows others to (re)use your design without getting bogged down in details that they are not currently interested in and allows them (and you when you re-use the design) to be more productive. Figure out where you are and where you want to be in the design productivity chain. The synthesis cost in terms of logic resource is zero, the upfront learning cost will start to pay back in the form of quicker debug and reusable designs. Kevin JenningsArticle: 131868
Eric Smith wrote: > Kevin Neilson wrote: >> Having two bits hot in a one-hot FSM would normally be a bad thing. >> But I was wondering if anybody does this purposely, in order to fork, >> which might be a syntactically nicer way to have a concurrent FSM. > > DEC used that style of design in the PDP-16 Register Transfer Modules. > Possibly also in the control units of some of their asynchronous > processors such as the PDP-6 and KA10. That's interesting--I'm not even familiar with an "asynchronous processor". What does that mean? -KevinArticle: 131869
KJ wrote: > On May 5, 12:13 pm, "Brad Smallridge" <bradsmallri...@dslextreme.com> > wrote: >>> You'll also find that changes (like switching the Nobl SRAM to DRAM as an >>> example) can be accomodated without having to change *everything*. ... > Designing a request/acknowledge interface to some other process or > entity (in this case the 'other' being a DRAM controller) results in a > much easier to maintain design. > > Using the exact same interface signal functionality whether one is > talking to internal FPGA memory, NoBL or SDRAM or SPI results in a > design that can be reused, retargeted and improved upon if necessary. ... > Kevin Jennings This is a great example, because switching from one type of RAM to another means you *do* have to change everything, if you want the controller to be good. You can certainly modularlize the code and make concurrent SMs with handshaking and this is easy to maintain. And a lot of DRAM controllers are designed this way. But here is the problem: while you are waiting around for acknowledges, you have just wasted a bunch of memory bandwidth. If you want to make better use of your bandwidth, you can't use handshaking. You have to start another burst while one is in the pipe. You have to look ahead in the command FIFO to see if the next request is going to be in the same row/bank to see if you need to close the row during this burst and precharge or if you can continue in the same open row in a different bank, etc. If I do all that with handshaking, I'm frittering away cycles. And to do this in a way that doesn't fritter away cycles with standard methodology means everything is so tightly bound together that to change from SDRAM to some other type of RAM means I have to tear up most of the design. Another issue I came up with today in the design of my current SM is that I updated a value x and then in the next cycle realized I wanted the old value of x. But I hadn't really updated x; I had issued a request that gets put into a matching delay line and then goes to a concurrent FSM which then updates x. So even though I had "updated" x, I could still used the old value for a few cycles and didn't need a temporary storage register. Again, I can't just send the request to update x and then wait for an ack because the SM has to keep on trucking. This is confusing, and I'd like to have some sort of methodology that would be as efficient as what I'm doing but somewhat more abstract. -KevinArticle: 131870
KJ wrote: > "Kevin Neilson" <kevin_neilson@removethiscomcast.net> wrote in message > news:fvfm29$on81@cnn.xsj.xilinx.com... >> KJ wrote: >>> "Kevin Neilson" <kevin_neilson@removethiscomcast.net> wrote in message >>> news:fv7i38$69n6@cnn.xsj.xilinx.com... >>>> My question: what is the cleanest way to describe an FSM requiring >>>> pipelining? >> ... >>> The other thing to consider is whether the latency being introduced by >>> this outsourced logic needs to be 'compensated for' in some fashion or is >>> it OK to simply wait for the acknowledge. In some instances, it is fine >>> for the FSM to simply wait in a particular state until the acknowledge >>> comes back. In others you need to be feeding new data into the >>> hunk-o-logic on every clock cycle even though you haven't got the results >>> from the first back. In that situation you still have the req/ack pair >>> but now the ack is simply saying that the request has been accepted for >>> processing, the actual results will be coming out later. Now the >>> hunk-o-logic needs an additional output to flag when the output is >>> actually valid. This output data valid signal would typically tend to >>> feed into a separate FSM or some other logic (i.e. 'usually' not the >>> first FSM). The first FSM controls feeding stuff in, the second FSM or >>> other processing logic is in charge of taking up the outputs and doing >>> something with it. >>> >> ... >>> Kevin Jennings >> In this case I do indeed have to continue to keep the pipe full, so >> inserting wait states is not an option. And the latency of the "hunk of >> logic", aka concurrent process, is actually significant because I have to >> get the result and feed it back into the FSM. This example shows why: >> >> STATE2: begin >> if (condition) >> begin >> state <= STATE3; >> y <= (a*b+c)*d; >> end >> end >> >> I have to get the result (a*b+c) and then feed it back into the FSM so I >> can multiply by d. Why not just let the concurrent process handle that? >> Because I want to limit my resource usage to a single DSP48, so I have to >> schedule the multiplications inside the FSM. But I'll have to check out >> the Wishbone thing you're talking about. > > Well, just the fact that you're time sharing the DSP48 means that you're not > processing something new on every clock cycle which just screams out to me > that you'd want to implement this with a request/acknowledge type of > framework. ... > > Kevin Jennings > > But I *do* have to process something on every cycle. Consider that I have to process these two equations: y0 <= (a0*b0+c0)*d0; y1 <= (a1*b1+c1); Now, if you look at the structure of the DSP48, you can see that I can't even process these two sequentially. I can send off (a0*b0+c0)*d0 to the black box thingy you speak of, but this can't be processed without dead cycles: I have to get the result of (a0*b0+c0) before I multiply it with d0, and if the DSP48 is fully pipelined, that means that the multiplier is unused for three cycles. It's similar to a superscalar process with dependencies. So I have to reschedule: I put (a0*b0+c0) into the pipe, then put in (a1*b1+c1) (which has no dependency on what is in the pipe), and then when the result of (a0*b0+c0) pops out I can feed it back into the DSP48 and multiply it with d0 to get y0. In the meantime y1 pops out. Without this intermixed scheduling I end up with too many dead cycles and then I need to use too many DSP48s. Maybe what I really want is a way to take the superscalar scheduling techniques that have been used for a long time and apply them in a similar way to HDL. -KevinArticle: 131871
Mike Treseler wrote: > Kevin Neilson wrote: > >> I have to get the result (a*b+c) and then feed it back into the FSM so I >> can multiply by d. Why not just let the concurrent process handle that? >> Because I want to limit my resource usage to a single DSP48, so I have >> to schedule the multiplications inside the FSM. > > I still like the idea of a step counter. > > On tick one, I do x <= a * b *c; > On tick two, I do y <= x * d; > and so on ... > > -- Mike Treseler That is essentially what I'm doing; I'm just trying to find a syntactically better way to design this pipelined stuff without having a bunch of interdependent concurrent FSMs (or a single FSM and a bunch of logic outside). -KevinArticle: 131872
Hi Goran,
The FSL_Full Flag is not asserted. Also, the microblaze came out of
reset. I know cos I probed the addr and data bus signals and there is
information on the bus in the modelsim simulator, wrt to when the
microblaze is not out of reset.
anyway, i found something else. This was what I wrote in my
firmware code running on microblaze:
#include "float.h"
#include "mb_interface.h"
typdef unsigned long long uint_64; //64 bits wide
typedef union {
uint_64 long_t;
double double_t;
} Union_double_t;
int main(){
Union_double_t a;
Xuint32 temp;
a= 3.0;
//extract the lower word to put into the peripheral
temp = (Xuint32) a.long_t & 0xffffffff;
microblaze_bwrite_fsl(temp,0);
//extract the upper word to put into the peripheral
temp = ((Xuint32) a.long_t >>32) | 0xffffffff;
microblaze_bwrite_fsl(temp,0);
return 1;
}
the code above does not work. In short, when i try to send a double
precision word onto the FSL bus like the manner described above by
breaking it into the lower word and the upper word, it fails to work.
However, for a single precision word sent in exactly the same way, it
works just fine.
any idea? :)
Chris
Article: 131873Silicon Wafers at PCASilicon.com PCA supplies silicon wafers for the semiconductor industry. Our products include wafers, thin films and more. We also offer polishing, reclaiming, slicing and lapping of wafers. http://www.ogogo123sina.cn/Silicon.htmArticle: 131874
On May 5, 12:06 pm, "MM" <mb...@yahoo.com> wrote: > I am not sure if this could be your problem, but... normally JTAG signals > require pullups. Oh? I've never used them before, but then again, I've only used iMPACT and the programming cable before... This one I can't do until Wednesday, but I will try tacking on some external pull-ups, if possible. Frankly, I don't have a lot of hope on this, but then again, nothing else seems to work either! > Bitgen can (and probably does) enable them internally, but > personally I've never relied upon them and always designed in external > resistors... Yes, Bitgen does enable them by default, and I didn't touch these... > The behaviour with iMPACT might be different because there > might be some pullups inside of the programming cable and/or simply the > drivers/receivers are different. Yeah, who knows?! > > /Mikhail Thanks, but unless the pullups work Wednesday, I'm not sure I'm any closer. I certainly appreciate all your comments! Any others? -Bob
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