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
KJ, thanks for your input. The issue came up when we started getting a glitch in one of our state machine outputs. It was a FSM we've been carrying from project to project for years. It has always worked and then stopped. Ultimately, the glitching was a result of ISE's auto setting doing something different from one version of ISE to the next. It was implementing the FSM in such a way that we were getting the glitch. I set the fsm encoding to "none" and the glitching went away. So,"trusting the synthesizer" is not always a good idea as I found the hard way. Especially in an aerospace project that needs to be DO-254 certified. I necessarily need to know what the synthesizer is doing. Had changing to a recent ISE version not caused the glitching, I would not be as concerned about it. I'm all about making portable code, but making 100% portable code is nearly impossible. If I don't use the nonportable attribute in the vhdl file then I still have to use the sysnthesizers nonportable GUI to set the encoding algorithm. Also, using the GUI method I cannot set multiple FSMs to different encoding algorithms. The GUI is all or none. If you know of a method that is 100% portable, I would be interested in that. Writing the FSM a certain way won't guarantee how the synthesizer implements it, that I know of. As stated in the 10.1 manual, XST extracts FSMs and encodes them according to the setting. DaleArticle: 136251
On 7 nov, 14:00, Leon <leon...@btinternet.com> wrote: > On 7 Nov, 18:00, Benjamin Couillard <benjamin.couill...@gmail.com> > wrote: > > > > > On 7 nov, 11:47, Leon <leon...@btinternet.com> wrote: > > > > On 7 Nov, 16:11, Benjamin Couillard <benjamin.couill...@gmail.com> > > > wrote: > > > > > On 7 nov, 05:25, mentari <Stephan...@gmail.com> wrote: > > > > > > What are your views onhttp://scratchpad.wikia.com/wiki/TileraMult= icore > > > > > as a replacement for FPGA's ? > > > > > >http://www.tilera.com/solutions/digital_baseband.php > > > > > > The current architecture for base stations fall short of deliveri= ng > > > > > the performance, the low latency and the flexibility customers ne= ed. > > > > > To meet the requirements, wireless equipment providers design com= plex > > > > > systems with FPGA, ASIC, DSP and processors with each component > > > > > requiring special tools in a customized development environment. = This > > > > > leads to a long development cycle, sometimes years, before > > > > > applications can be productized. Changes in standards also impact > > > > > providers because such systems are inflexible-upgrades can be a s= low > > > > > and expensive process. > > > > > > What providers seek is an uncomplicated, well-designed, architect= ure > > > > > that yields good performance. Tilera's processors provide a low > > > > > latency single solution that integrates many functions seamlessly= in a > > > > > single processor and uses C/C++ to program their applications wit= h > > > > > industry standard tools. The familiar tools enable customers to > > > > > preserve their software investments, replace a number of disparat= e > > > > > programming methodologies with one standard programming environme= nt, > > > > > and gain the flexibility they need to support evolving protocols = and > > > > > ever-increasing demands for service > > > > > It seems to be similar to XMOS devices. I suppose that it could > > > > replace FPGAs in some applications. However, it's still a much coar= ser > > > > architecture than an FPGA. =A0There's still only 64 processing unit= s, > > > > while a Virtex-5 can have about 20 000 slices and a couple of PPC > > > > processors. In the end, I think that since FPGAs are much more > > > > flexible, they have the upper hand. Plus with tools like system > > > > generator, AccelDSP and Simulink, low-level HDL coding can be skipp= ed, > > > > and the engineer can focus more on applications and less on the "bi= t- > > > > level" of things. > > > > > Plus I suppose that with a high-capacity FPGA, one could emulate a > > > > Tilera-like device with 64 processing units. Maybe the future's the= re, > > > > take the Tilera (or Xmos) concept and implement it in a FPGA. > > > > > My 2 cents > > > > They will cost more, be much harder to use, use a lot more power and > > > won't be any faster. > > > > Leon > > > THe point is not that it will be faster, is that it'll be much more > > versatile since you won't be stuck with a fixed architecture > > You won't have 64k per core, and what about stuff like 100 MHz I/Os, > hardware threads switching in one cycle, and 3.2 Gb/s full duplex > links between cores? > > Leon You raise some good points. But, I was just making the point that you could implement some sort of "xmos-like" architecture in a big FPGA. While you wouldn't have 64k per core , you would certainly be able to have 3.2 Gb/s full duplex (32 bits @ 100 MHz). But anyay, I think that FPGAs are there to stay and they have a big future in front of them. There might be some applications where they'll be replaced by faster, cheaper technologies, but the reverse is also true.Article: 136252
mentari <StephanusR@gmail.com> writes: > What are your views on http://scratchpad.wikia.com/wiki/TileraMulticore Are they cache coherent? If not what types of libraries do they provide, e.g. is MPI supported? What about debuggers for the architecture? Petter -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail?Article: 136253
On 7 Nov, 19:26, Benjamin Couillard <benjamin.couill...@gmail.com> wrote: > On 7 nov, 14:00, Leon <leon...@btinternet.com> wrote: > > > > > On 7 Nov, 18:00, Benjamin Couillard <benjamin.couill...@gmail.com> > > wrote: > > > > On 7 nov, 11:47, Leon <leon...@btinternet.com> wrote: > > > > > On 7 Nov, 16:11, Benjamin Couillard <benjamin.couill...@gmail.com> > > > > wrote: > > > > > > On 7 nov, 05:25, mentari <Stephan...@gmail.com> wrote: > > > > > > > What are your views onhttp://scratchpad.wikia.com/wiki/TileraMu= lticore > > > > > > as a replacement for FPGA's ? > > > > > > >http://www.tilera.com/solutions/digital_baseband.php > > > > > > > The current architecture for base stations fall short of delive= ring > > > > > > the performance, the low latency and the flexibility customers = need. > > > > > > To meet the requirements, wireless equipment providers design c= omplex > > > > > > systems with FPGA, ASIC, DSP and processors with each component > > > > > > requiring special tools in a customized development environment= . This > > > > > > leads to a long development cycle, sometimes years, before > > > > > > applications can be productized. Changes in standards also impa= ct > > > > > > providers because such systems are inflexible-upgrades can be a= slow > > > > > > and expensive process. > > > > > > > What providers seek is an uncomplicated, well-designed, archite= cture > > > > > > that yields good performance. Tilera's processors provide a low > > > > > > latency single solution that integrates many functions seamless= ly in a > > > > > > single processor and uses C/C++ to program their applications w= ith > > > > > > industry standard tools. The familiar tools enable customers to > > > > > > preserve their software investments, replace a number of dispar= ate > > > > > > programming methodologies with one standard programming environ= ment, > > > > > > and gain the flexibility they need to support evolving protocol= s and > > > > > > ever-increasing demands for service > > > > > > It seems to be similar to XMOS devices. I suppose that it could > > > > > replace FPGAs in some applications. However, it's still a much co= arser > > > > > architecture than an FPGA. =A0There's still only 64 processing un= its, > > > > > while a Virtex-5 can have about 20 000 slices and a couple of PPC > > > > > processors. In the end, I think that since FPGAs are much more > > > > > flexible, they have the upper hand. Plus with tools like system > > > > > generator, AccelDSP and Simulink, low-level HDL coding can be ski= pped, > > > > > and the engineer can focus more on applications and less on the "= bit- > > > > > level" of things. > > > > > > Plus I suppose that with a high-capacity FPGA, one could emulate = a > > > > > Tilera-like device with 64 processing units. Maybe the future's t= here, > > > > > take the Tilera (or Xmos) concept and implement it in a FPGA. > > > > > > My 2 cents > > > > > They will cost more, be much harder to use, use a lot more power an= d > > > > won't be any faster. > > > > > Leon > > > > THe point is not that it will be faster, is that it'll be much more > > > versatile since you won't be stuck with a fixed architecture > > > You won't have 64k per core, and what about stuff like 100 MHz I/Os, > > hardware threads switching in one cycle, and 3.2 Gb/s full duplex > > links between cores? > > > Leon > > You raise some good points. > But, I was just making the point that you could implement some sort of > "xmos-like" architecture in a big FPGA. While you wouldn't have 64k > per core , you would certainly be able to have 3.2 Gb/s full duplex > (32 bits @ 100 MHz). > > But anyay, I think that FPGAs are there to stay and they have a big > future in front of them. There might be some applications where > they'll be replaced by faster, cheaper technologies, but the reverse > is also true. They won't replace them completely, of course, but there will be many applications where the ease of development (a C-like language with compilation and testing in a few seconds) and low cost will see them being used in place of FPGAs, and in conjunction with them. One application I've heard of uses a CPLD as an XLink interface to an XMOS chip, and I'm thinking of using an FPGA between an RF ADC and the XMOS chip for a software defined radio. LeonArticle: 136254
On Nov 7, 2:23 pm, Dale <dale.prat...@gmail.com> wrote: > KJ, thanks for your input. The issue came up when we started getting > a glitch in one of our state machine outputs. Then the design error would appear to be that this state machine output is not the output of a flip flop as it should be since it is apparently required to be glitchless. One way to fix it would be to find the logic for that code and get it inside of a clocked process. > It was a FSM we've been > carrying from project to project for years. It has always worked and > then stopped. The state machine stopped because of a glitch on an output??? That doesn't make much sense on a couple fronts: - State machine outputs do not affect the operation of the state machine. Maybe what you mean is that this glitch caused some other logic to fail. - A glitch that causes a functional problem is indicative of not following a synchronous design process which is always bad news in an FPGA...even if something that has 'worked for years' (but in different designs). > Ultimately, the glitching was a result of ISE's auto > setting doing something different from one version of ISE to the > next. It was implementing the FSM in such a way that we were getting > the glitch. What you should be investigating is why the glitch caused any sort of failure. Synchronous designs work well in FPGAs, non-synchronous ones will (with near certainty) eventually fail under some conditions. Until you get rid of the logic that is failing due to the glitch your design is likely to be fragile. > I set the fsm encoding to "none" and the glitching went > away. So,"trusting the synthesizer" is not always a good idea as I > found the hard way. Especially in an aerospace project that needs to > be DO-254 certified. I necessarily need to know what the synthesizer > is doing. Had changing to a recent ISE version not caused the > glitching, I would not be as concerned about it. > Yeah, but now that you are concerned you really need to get to the true root cause. Fiddling with tool settings to make it appear to work is setting yourself up for headaches down the road because you haven't really identified the root cause of the problem, you've only identified a band-aid that appears to fix the problem but does not address the root cause because that has not yet been identified. > I'm all about making portable code, but making 100% portable code is > nearly impossible. If I don't use the nonportable attribute in the > vhdl file then I still have to use the sysnthesizers nonportable GUI > to set the encoding algorithm. Also, using the GUI method I cannot > set multiple FSMs to different encoding algorithms. The GUI is all or > none. If you know of a method that is 100% portable, I would be > interested in that. > > Writing the FSM a certain way won't guarantee how the synthesizer > implements it, that I know of. As stated in the 10.1 manual, XST > extracts FSMs and encodes them according to the setting. > Like I mentioned above, I think you really need to get to the bottom of why a glitch on a particular signal causes a failure in the first place. However, to address this particular point of how to write code that guarantees a particular encoding, here is the following snippet. Basically, instead of defining an enumerated type, you define a std_logic_vector of the appropriate width and then define an array constant with the names you'd like to associate with those encodings. type StateStd_Typ is array(State_Typ) of std_logic_vector(1 downto 0); , constant State2Std_c : StateStd_Typ := (IDLE => "00", FETCH => "01", DECODE => "10", EXECUTE => "11); Good luck. Kevin JenningsArticle: 136255
On Nov 7, 10:38=A0am, uraniumore...@gmail.com wrote:
> Hello all,
>
> I am having some issues with this piece of code, which is supposed to
> work correctly with the spartan 3 leds.
> I am trying to display a 16 bit count to the led display; however, the
> value on the leddisplay produces duplicate values across all 4 leds.
> Is there something I am doing wrong with the code ?
>
> Please help,
> Uchenna Anyanwu
>
> always @ ( posedge done or posedge reset)
> begin
> if(reset)
> leddisp <=3D 0;
> else
> leddisp[15:0] <=3D numcounter1 - numcounter2;
> go =3D 1;
> end
>
> always @ (posedge go)
> begin
> if(go)
> difcount1=3D{leddisp[3], leddisp[2], leddisp[1],leddisp[0]};
> end
>
> always @ (posedge go)
> begin
> if(go)
> difcount2=3D{leddisp[7], leddisp[6], leddisp[5], leddisp[4]};
> end
>
> always @ (posedge go)
> begin
> if(go)
> difcount3=3D{leddisp[11], leddisp[10], leddisp[9], leddisp[8]};
> end
>
> always @ (posedge go)
> begin
> if (go)
> difcount4=3D{leddisp[15], leddisp[14], leddisp[13], leddisp[12]};
> end
>
> led u3 (difcount1,s0, s1, s2, s3, s4, s5, s6);
> led u4 (difcount2,s7, s8, s9, s10, s11, s12, s13);
> led u5 (difcount3,s14, s15, s16, s17, s18, s19,s20);
> led u6 (difcount4,s21, s22, s23, s24, s25, s26, s27);
>
> LED_MUX u7 (/*clkbuf*/ clk_50Mhz, reset, {s6, s5, s4, s3, s2, s1, s0},
> {s13,s12,s11,s10,s9,s8,s7}, {s20,s19,s18,s17,s16,s15,s14},
> {s27,s26,s25,s24,s23,s22,s21}, LEDOUT, LEDSEL );
>
> endmodule
>
> module led(number, s0, s1, s2, s3, s4, s5, s6);
> output s0, s1, s2, s3, s4, s5, s6;
> input [3:0] number;
> reg s0, s1, s2, s3, s4, s5, s6;
> always @ (number)
> begin // BCD to 7-segment decoding
> case (number) // s0 ? s6 are active low
> 4'b0000: begin s0=3D0; s1=3D0; s2=3D0; s3=3D1; s4=3D0; s5=3D0; s6=3D0; en=
d
> 4'b0001: begin s0=3D1; s1=3D0; s2=3D1; s3=3D1; s4=3D0; s5=3D1; s6=3D1; en=
d
> 4'b0010: begin s0=3D0; s1=3D1; s2=3D0; s3=3D0; s4=3D0; s5=3D1; s6=3D0; en=
d
> 4'b0011: begin s0=3D0; s1=3D0; s2=3D1; s3=3D0; s4=3D0; s5=3D1; s6=3D0; en=
d
> 4'b0100: begin s0=3D1; s1=3D0; s2=3D1; s3=3D0; s4=3D0; s5=3D0; s6=3D1; en=
d
> 4'b0101: begin s0=3D0; s1=3D0; s2=3D1; s3=3D0; s4=3D1; s5=3D0; s6=3D0; en=
d
> 4'b0110: begin s0=3D0; s1=3D0; s2=3D0; s3=3D0; s4=3D1; s5=3D0; s6=3D0; en=
d
> 4'b0111: begin s0=3D1; s1=3D0; s2=3D1; s3=3D1; s4=3D0; s5=3D1; s6=3D0; en=
d
> 4'b1000: begin s0=3D0; s1=3D0; s2=3D0; s3=3D0; s4=3D0; s5=3D0; s6=3D0; en=
d
> 4'b1001: begin s0=3D0; s1=3D0; s2=3D1; s3=3D0; s4=3D0; s5=3D0; s6=3D0; en=
d
> default: begin s0=3D1; s1=3D1; s2=3D1; s3=3D1; s4=3D1; s5=3D1; s6=3D1; en=
d
> endcase
> end
> endmodule // end led
>
> module LED_MUX (clk, rst, LED0, LED1, LED2, LED3, LEDOUT, LEDSEL);
> input clk, rst;
> input [7:0] LED0, LED1, LED2, LED3;
> output[3:0] LEDSEL;
> reg [3:0] LEDSEL;
> output[6:0] LEDOUT;
> reg [6:0] LEDOUT;
> reg [1:0] index;
> always @(posedge clk)
> begin
> if(rst)
> index =3D 0;
> else
> index =3D index + 1;
> end
> always @(index or LED0 or LED1 or LED2 or LED3)
> begin
> case(index)
> 0: begin
> LEDSEL =3D 4'b1110;
> LEDOUT =3D LED0;
> end
> 1: begin
> LEDSEL =3D 4'b1101;
> LEDOUT =3D LED1;
> end
> 2: begin
> LEDSEL =3D 4'b1011;
> LEDOUT =3D LED2;
> end
> 3: begin
> LEDSEL =3D 4'b0111;
> LEDOUT =3D LED3;
> end
> default: begin
> LEDSEL =3D 0; LEDOUT =3D 0;
> end
> endcase
> end
> endmodule
Are you sure that LEDSEL is active low? If it connects directly to
the LED
anodes I would guess it should be active high.
Article: 136256Benjamin Couillard wrote: > You raise some good points. > But, I was just making the point that you could implement some sort of > "xmos-like" architecture in a big FPGA. While you wouldn't have 64k > per core , you would certainly be able to have 3.2 Gb/s full duplex > (32 bits @ 100 MHz). > > But anyay, I think that FPGAs are there to stay and they have a big > future in front of them. There might be some applications where > they'll be replaced by faster, cheaper technologies, but the reverse > is also true. True, but FPGA markets will suffer from short lifetimes. As soon as the use gets sufficently stable, and the volumes ramp, someone comes along with a Silicon solution that displaces the FPGA Here is a good example = Freescale have just released a 6 core DSP www.freescale.com%2F&esheet=5822117&lan=en_US&anchor=www.freescale.com&index=1 This targets applications that used DSP+FPGA before. Of course, the MSC8156 AND a FPGA will be more powerful again... -jgArticle: 136257
Mentari - Please do us the favor of identifying yourself as an interested party in Tilera or tell us why you're posting here in comp.arch.fpga with absolutely no apparent history in this newsgroup. It's often okay for an occasional post from a company with a new, compelling architecture to stir interest on a very related newsgroup, but not so much through pretext. Participants in this newsgroup have had tremendous interactions in the past with professionals from the compainies involved in products for the markets we work in. Personally, I don't like people passing themselves off as "random interested party" when they're a pump & dump investor or a marketing person trying to "sneak in" some interest as if it's a grass roots effort. If you have no affiliation with the company or its products, you are certainly an unusual participant in this group with complete, well thought-out communication down to the detail of your diction to the extent that engineering doesn't appear to your primary interest. Engineers can communicate well but we're often more interested in the meat and meaning of the conversation rather than well considered prose. You look like marketing. If you really are an interested engineer, more power to ya. But I don't like looking at threads with strong suspicion. - John_HArticle: 136258
Felix Stocker wrote: > Hi > > I have a stupid question. I try to locate where my units of the > floorplaner are then actually on the physical chip! > So I am wondering there where the physical chip has its mark (a point) > I assume that is Slice X0Y0 is that right? If that is the case then the > Floorplaner would be quite confusing as it has X0Y79 in the upper left > corner. > > Thanks for clarification ;) > Silly Boy Look at FPGA Editor for the coordinates. Different silicon from different vendors can have the origin in a different location depending on whether the numbering basis is 1) a printed page order (please note at least 3 differences in read direction for different languages - I'm thinking english, hebrew, and traditional chinese), 2) a common graphical system based on cartesian coordinates, and 3) whether the silicon is a flip chip such that the orientation to the user (looking at the package top) does not represent the silicon's "top" side. I think the X0Y0 is typically the lower left in Xilinx devices corresponding to a catesian coordinate system used in most mathematics. - John_HArticle: 136259
Kevin, you bring up some interesting points. I've pasted the state machine in question. It's a very simple FSM. Let me explain the glitching a little better. Maybe my sentence was confusing when I said "it stopped". I meant to say it stopped working as desired (the glitch). The output of the FSM was glitching. Specifically signals U_nWR1, U_nRD1 and U_ADS (seen below). These are control signals for a UART. When those signals glitch the UART's timing constraints aren't met and the communication with the UART fails. Do you see a problem with how this state machine is coded? Thanks again. process (H1) begin if H1'event and H1 = '0' then if nReset_B='0' then Sreg0 <= "001"; -- S0 Sreg1 <= "01"; -- S0 else case Sreg0 is when "001" => -- S0 if nPage3_244='0' then Sreg0 <= "000"; -- S1 else Sreg0 <= "001"; -- S0 end if; when "000" => --S1 Sreg0 <= "010"; --S2 when "010" => -- S2 Sreg0 <= "100"; --S3 when "100" => --S3 Sreg0 <= "111"; --S4 when "111" => --S4 if nPage3_244='1' then Sreg0 <= "001"; -- S0 else Sreg0 <= "111"; -- S4 end if; when others => -- trap state Sreg0 <= "001"; -- S0 end case; case Sreg1 is when "01" => -- S0 if nPage3_244='0' then Sreg1 <= "10"; -- S1 else Sreg1 <= "01"; -- S0 end if; when "10" => --S1 Sreg1 <= "11"; --S2 when "11" => --S2 if nPage3_244='1' then Sreg1 <= "01"; -- S0 else Sreg1 <= "11"; -- S2 end if; when others => -- trap state Sreg1 <= "01"; -- S0 end case; end if; end if; end process; U_nRD1 <= Sreg0(0) when nReset_B = '1' and RnW = '1' else '1'; U_nWR1 <= Sreg0(0) when nReset_B = '1' and RnW = '0' else '1'; U_nADS <= Sreg1(0);Article: 136260
> Well I think that designing a face-recognition system in VHDL (or > Verilog) would be a huge waste of time and it would be really hard to > do. There are tools for that, to automate conversion from Matlab to > HDL (AccelDSP, system generator). I'm pretty sure that there are FPGA- > neutral tools too for Matlab (that would work on both Altera and > Xilinx) Such as Synplify DSP, from Synplicity. Supports all major devices vendors, even ASIC technology. Francois ChoquetteArticle: 136261
On Tue, 04 Nov 2008 16:56:21 +0100, Guenter Dannoritzer <kratfkryksqq@spammotel.com> wrote: >http://www3.elphel.com/ > >The source of those cameras is available as open source and one of the >first camera models using M-JPEG has an encoder based on the XAPP610. I >assume the author did get it to work. > >If not, there are several examples of JPEG encoders on opencores. Thanks for the hint. I found a working DCT inside the "Video compression systems" on opencores. The otherones on opencores also didn't really work for me. Maybee I didn't gave them the right control signals... I don't know. However now everything is working. Regards, MichaelArticle: 136262
"Dale" <dale.prather@gmail.com> wrote in message news:58b81a5b-879b-49b9-b76b-f71530834267@d36g2000prf.googlegroups.com... > The output of the FSM was glitching. Specifically signals > U_nWR1, U_nRD1 and U_ADS (seen below). These are control signals for > a UART. When those signals glitch the UART's timing constraints > aren't met and the communication with the UART fails. Do you see a > problem with how this state machine is coded? Thanks again. > Given these equations, I can see good glitch potential for 'U_nRD1' and 'U_nWR1' but not for 'U_nADS'. The read and write controls are the output of combinatorial logic, not a flip flop which as I stated in the previous post can always glitch even if 'RnW' is also an output of a flip flop that is also clocked by 'H1'. To test this hypothesis and see if this really is the root cause, you'll need to have a scope on 'U_nADS', 'U_nRD1' and 'RnW' (if that one is externally available) and trigger on a glitch on 'U_nRD1' (or instead of 'U_nRD1' use 'U_nWR1' if that is more likely to glitch). I suspect you'll see that the glitch is occurring at either an edge on 'U_nADS' or 'RnW'. > U_nRD1 <= Sreg0(0) when nReset_B = '1' and RnW = '1' else '1'; > U_nWR1 <= Sreg0(0) when nReset_B = '1' and RnW = '0' else '1'; > U_nADS <= Sreg1(0); To get rid of glitches on these two, you'll need to move them into the clocked process (and presumably change the logic somewhat if you don't want them to come out one H1 clock cycle later). The strobe signal already is the output of a flip flop as far as synthesis is concerned because concurrent assignments like x <= y; or x <= not(y) are 'free' in the sense that they don't use any logic. Another alternative is to move all three into the clocked process almost verbatim (change the 'when/else' into the equivalent 'if/else'). This delays all three control signals by the same amount so you haven't skewed the relative timing among the three. But you'll probably also have to delay some address and data signals that are probably involved as well so that they stay in sync with the now delayed control signals. But that's how you engineer the proper fix. Along some other lines of thought that may or may not be applicable depending on what you find with the above... Your state machine already has hard coded discrete values for the states so no matter what you do with synthesis attributes the logic implementing 'Sreg0' and 'Sreg1' will not be any different so the whole path you've been going down in this post regarding trying to control the encoding isn't going to do anything to fix the problem. If there are other places in your design where you do use an enumerated type, changing the encoding could affect that section which could then in turn impact timing of logic in this block which could be why you saw some difference. This just an observation not any sort of problem. Are all the state machine inputs synchronous to H1? (looks like just nReset_B, nPage3_244). If not, I wouldn't really expect a glitch but you could end up transferring to the wrong state. By 'glitch', I'm assuming you mean something that was just a few ns long, not something that lasted for an entire 'H1' clock cycle. If it was a clock cycle wide type of glitch then this is not really what is normally called a 'glitch', but the problem then would be because the signal 'nPage3_244' is not synchronous to H1. Somewhat along those lines as well... - Is RnW synchronous to H1? If not, then you'll see glitches because of the skew between Sreg0(0) and RnW. RnW will also need to be synchronous to H1 anyway in order to implement the change I mentioned above about moving the control signal logic into the clocked process. - Is RnW a signal from this same design or does it come from a different part? If from a different part, then how are you controlling skew on H1 between these two devices? Have you measured the skew? Kevin JenningsArticle: 136263
Hi everyone.
I have a Xilinx ML555 and Linux as OS.
The job assigned to me is linux programming for "Data transfer
between CPU and FPGA over PCI bus".
Someone already did the similar thing. Please help me.
General flow is like this.
(1) CPU sends data to FPGA
(2) FPGA do computations
(3) FPGA gives it back to CPU
What I want to ask is following.
(1) This is the first time for Linux programming.
Where can I get the sample codes or reference?
(2) I think that initially FPGA chip is not configured.
So How to configure it? ( I mean that if I have a bitstream file
for FPGA, How can I configure FPGA with it?)
(3) If you have already done with similar job, plz give me an advice
about how to proceed.
I have to do it myself, so even a little advice is big help for
me.
Thanks in advance.
Article: 136264I've just downloaded the latest Altera Web Edition software. I was pleased to see that they have removed the requirement for a license that has to be renewed every six months. NIOS II is provided free, also. LeonArticle: 136265
On Nov 7, 11:09 pm, John_H <newsgr...@johnhandwork.com> wrote: > Mentari - > > Please do us the favor of identifying yourself as an interested party > in Tilera or tell us why you're posting here in comp.arch.fpga with > absolutely no apparent history in this newsgroup. I am not a engineer just somebody trying to figure out what it will cost to pay an FPGA engineer to build a ODFM LTE or Wimax base station that I can interface to any http://scratchpad.wikia.com/wiki/RfTransceiver I have contacted http://scratchpad.wikia.com/wiki/SeaSolve but they don't license their 802.16e MAC and PHY cores to the public only to Telco's. Is there some sort of conspiracy by Vodacom to prevent people from building their own Wimax towers on say 450mhz like Flarion FLASH-OFDM in the Nordic countries. ? How complicated is it our how long will it take an engineer to build 802.16e MAC/PHY and at what cost. Please help me out.Article: 136266
On 8 Nov, 07:05, Leon <leon...@btinternet.com> wrote: > I've just downloaded the latest Altera Web Edition software. I was > pleased to see that they have removed the requirement for a license > that has to be renewed every six months. NIOS II is provided free, > also. > > Leon Sorry, it's actually the NIOS II IDE that is available. I don't think that the IP is free. LeonArticle: 136267
"Leon" <leon355@btinternet.com> wrote in message news:72a2ae6c-52c3-416d-a075-9ad1e483de2c@b38g2000prf.googlegroups.com... > On 8 Nov, 07:05, Leon <leon...@btinternet.com> wrote: >> I've just downloaded the latest Altera Web Edition software. I was >> pleased to see that they have removed the requirement for a license >> that has to be renewed every six months. NIOS II is provided free, >> also. >> >> Leon > > Sorry, it's actually the NIOS II IDE that is available. I don't think > that the IP is free. > > Leon The important thing, for me, is that Modelsim Altera-Edition has *finally* been upgraded to a MODERN version (6.3g.) Full end-to-end SYSTEMVERILOG in ALTERA tool-flow! Simulation, RTL Synthesis, (basic) SV testbench. (Advanced SV testbench still requires commercial license of Questasim + Modelsim/SE)Article: 136268
"m" <martin.usenet@gmail.com> wrote in message news:3b479dc1-ac2d-41a0-8a44-9e8a51511309@a29g2000pra.googlegroups.com... > I'm interested to hear from anyone who has experience implementing > Linux on Microblaze. How "smooth" is it? What are the pitfalls? > Limitations/issues? > > I am not talking about uClinux but rather the MMU version/s. > > I hear conflicting reports. Hard processor vendors bash the heck out > of it and tell us that it is an absolute nightmare (gee, I wonder > why?). Xilinx and the disti are telling us that all will be fine. *ANY* softcore FPGA embedded CPU (Microblaze, Nios-II) is so slow, why would you even try to run a full Linux (MMU) kernel on it? It may be academically interesting, but a far more practical setup would use a Virtex4/FX (PowerPC-405) or a Virtex5/FXT (PowerPC-440)Article: 136269
A year ago, I heard Synplicity's (RTL synth) Systemverilog support was terrible. Altera Quartus-II 8.1 supports Systemverilog quite well (interfaces, enums, typedefs, unique/priority case, always_comb/always_ff, etc.) Not everything yet, but very usable. So how does the current version of Synplicity compare, in terms of Systemverilog language support?Article: 136270
On 2008-11-08, KJ <lkjrsy@gmail.com> wrote: > (1) This is the first time for Linux programming. > Where can I get the sample codes or reference? It is actually not that hard to write a driver for Linux, but when doing some initial experiments you don't even need a driver. I posted something about this some time ago on c.a.f: http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/5171491963302b63 /AndreasArticle: 136271
On 8 Nov., 08:23, "guestuser1" <guestus...@nowhere.net> wrote: > A year ago, I heard Synplicity's (RTL synth) Systemverilog support was > terrible. > > Altera Quartus-II 8.1 supports Systemverilog quite well (interfaces, > enums, typedefs, unique/priority case, always_comb/always_ff, etc.) > Not everything yet, but very usable. > > So how does the current version of Synplicity compare, in terms of > Systemverilog language support? 9.4L tested still bad. Stay away from Synplicity for 1 year before testing again. Maybe you'll discover its redundancy or even synplicity will discover theirs.Article: 136272
On Nov 8, 2:21 am, "guestuser1" <guestus...@nowhere.net> wrote: > *ANY* softcore FPGA embedded CPU (Microblaze, Nios-II) is so slow, > why would you even try to run a full Linux (MMU) kernel on it? I would think that a system with an MMU would quite likely be more efficient than one without, both in overhead for many operations (which have to be done a bit oddly / emulated in uClinux without MMU) and also in memory allocation efficiency. As for why someone might run linux on an embedded system in general - quite possibly because features and portability are more important than raw speed. Especially with FPGA fabric sitting right next door, there's an implication that what has to be fast is done in logic, while the processor and O/S are concerned with the complexities of talking protocols to other computers, talking to humans, and quite possibly running a fair amount of legacy code. Yes, the hybrid powerPC/FPGAs would be an option there too, but as a more specific part that may imply some undesired lock-in or at least restriction on choices. Anybody put a hard core processor in a spartan/cyclone class part yet? Wheras those are mainstays for smaller soft-core systems.Article: 136273
cs_posting@hotmail.com wrote: > On Nov 8, 2:21 am, "guestuser1" <guestus...@nowhere.net> wrote: > >> *ANY* softcore FPGA embedded CPU (Microblaze, Nios-II) is so slow, >> why would you even try to run a full Linux (MMU) kernel on it? > > I would think that a system with an MMU would quite likely be more > efficient than one without, both in overhead for many operations > (which have to be done a bit oddly / emulated in uClinux without MMU) > and also in memory allocation efficiency. > Generally speaking, running *without* an MMU is more efficient - people have been known to specifically choose no-MMU on devices such as large ARMs that have an MMU, because they want to avoid the overhead it needs. In particular, an MMU will increase the latency for memory accesses (how significant this is depends on whether the MMU translation is before or after the cache, and on the rest of the memory access path), it will increase task switching time (since MMU setup needs to be swapped), and it means that all data sharing between processes needs to use "proper" channels - without an MMU, processes can cheat and directly access each others memory spaces. For the particular case of memory allocation, however, an MMU will let the system use memory more efficiently. It will also save space (and possibly time) if there are sections of code and data that are shared between processes but must appear as private. > As for why someone might run linux on an embedded system in general - > quite possibly because features and portability are more important > than raw speed. Especially with FPGA fabric sitting right next door, > there's an implication that what has to be fast is done in logic, > while the processor and O/S are concerned with the complexities of > talking protocols to other computers, talking to humans, and quite > possibly running a fair amount of legacy code. > > Yes, the hybrid powerPC/FPGAs would be an option there too, but as a > more specific part that may imply some undesired lock-in or at least > restriction on choices. Anybody put a hard core processor in a > spartan/cyclone class part yet? Wheras those are mainstays for > smaller soft-core systems. My understanding of Altera's FPGAs is that they have pretty much given up on using ARM hard-core processors, because the Nios / Nios II was actually faster for real use - the flexibility of memory bus arrangements, custom instructions, etc., meant that the space taken by the ARM core was simply not worth it.Article: 136274
>LittleAlex wrote: > > >> Just to pick a nit.... > >> RS-232 does have a protocol. RTS-CTS, DSR-DTR, etc. V.24 describes >> the signal levels without mentioning the signal assertion/response. > >True, but much of it is rarely used. In the days of half >duplex communication with line turn around (the hardware >could physically only transmit one direction at a time) >that protocol was needed. For connecting a terminal to >a modem, or a computer to a printer, it isn't needed >and isn't used. > >> So the OP is really saying "I want RS-232 protocol WITHOUT the >> protocol". Still a miss-formed question. > >See above. > >-- glen > > thanks a bunch of all the comments here.... so far i manage to taken care of the reciever part of the rs232 bus controller, but im still having problem with transmitter part.. any idea how to come out with the state machine of transmitter part ? ... guidance is much appreciated
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