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
Ken Soon wrote: > Hmm why in this case the > dout1 <= dout2; > dout <= dout1; > is being placed outside the enable block then? Because I do not want any > latency when retrieving data? > I hope this does not add on any timing delay, if not I could be keeping on > adding register level in vain. Each added register will add a latency cycle, what you need to do is make sure that all the data comes together with matched latencies. I put the extra dout registers outside any ifs because the extra control logic for bringing the clock/read-enable further down would not have any net effect. > And really thanks alot for the code, it was spot on. I guess I could never > figured the part about the address and enable needing to be delayed myself. > Hmm come to think of it, it looks kind of stupid to do reassignment of > signals in the same block. If you continue to work with FPGAs and relatively high-speed designs, you will find that it is often a fundamental necessity. > From there on, I found out that I need to select register balancing => Yes > in synthesis option. > After doing so, the timing code really dropped by more significant amounts. Balancing and the other related options are necessary to let XST move registers around when you want to use "automatic pipelining". Unless some of these options are enabled, extra registers get synthesized as plain extra registers that do nothing more than delay data. Since each extra register optimization option gives XST more freedom in redistributing FFs, synthesis will be slower. > Oh btw I have then tried to add on more register levels. > Have tried some structures, and I deduce this coding should be logical. > Wonder if there is anything wrong. The lowest I have brought the timing down > is a slack of about 1ns There are limits to how many registers XST is able to move around when using automatic pipelining and it appears to vary from two to four depending on constructs and tool versions.Article: 118076
Good afternoon.. Has anyone being lucky in the past getting a Synplify for Linux evaluation license? Mentor has some online feedback form to request an evaluation license, but apparently their eimail goes always to /dev/null (o; I received the ispLever for Linux including license from Lattice directly but as you know the more expensive software lacks any synthesizing tools... I know I could switch to Windows..but..I already have it... (thanx again to Lattice Semiconductor for their great support sponsoring me software/hardware ;o) I just need the Linux version for porting several software to the Linux platform.... cheers rickArticle: 118077
Sebastien Bourdeauducq wrote: > Ok, thanks :) > > But why is slew rate related to resistance to short-circuits ? What is slew rate? It is how fast a signal goes from one voltage to another. What limits slew rate? Mostly path impedance, capacitance and driver strength. IOBs use current-limited output drivers for slow slew while fast-mode current is only limited by the output drivers MOS' impedance... over 100mA per pin - a few shorts to ground with those and you can burn out the Vccio bonding wires/traces, assuming the output drivers can survive a sustained short at this power level (150-400mW each) in the first place.Article: 118078
HDL simulation only. Just simulated the pieces of the interface and it worked when it was implemented in a V2P20 Jeff Cunningham wrote: > Eli Hughes wrote: >> I had to implement a PLB master the other year for a project. To be >> honest, it is actually easier if you just get the core connect spec >> and write it your self. >> >> In my case, I was only doing 64-bit transfers. The logic was actually >> pretty simple. I spent a week with the IPIF and it never really >> worked right. I told a co-worker that I did not think they ever >> tested the IPIF master operation. >> >> My own implementation only took a day or 2. Believe it or not the >> state machine to do is pretty small. > > Eli, > Just curious, did you debug it with HDL simulation or chipscope?Article: 118079
"Daniel S." <digitalmastrmind_no_spam@hotmail.com> wrote in message news:Ic3Vh.17620$iq5.533929@wagner.videotron.net... > > IOBs use current-limited output drivers for slow slew Hi Daniel, Can you point me to a reference for this statement? Thanks, Syms.Article: 118080
On 16 Apr 2007 15:00:55 -0700, "mmihai" <iiahim@yahoo.com> wrote: >On Apr 16, 1:39 pm, "mmihai" <iia...@yahoo.com> wrote: > >> [...] >> Requirement: 10.000ns >> Data Path Delay: 10.679ns (Levels of Logic = 4) >Inspired by a recent thread in this newsgroup (look for "Xilinx ISE >9.1 subject") I've tried "par" with different (default is 1) "cost >table" values (-t option) and it seems this option helps in meeting >the target timing. With "-t 2" I'm getting: > >Timing summary: >--------------- > >Timing errors: 0 Score: 0 > It's quite normal to get timing variations of a few percent from (a) extremely minor changes to the design and (b) changes to the "cost table" setting (or random seed). If I fail to meet timings by less than 10%, one option is to run MPPR overnight, to place/route with 10 or more different seeds - usually at least one makes it through timings. Failing that, if I don't want to modify the design, I look at the best failing pass in FPGA Editor, and often the problem is only a few absurdly badly placed components, which I can unroute, move, then let reentrant routing take over. As I understand it, the placer places components apparently randomly, then evaluates the "cost" i.e. difficulty of routing, according to a number of factors, placing a (slightly arbitrary) cost weighting on things like distance between related components, and congestion. Then it repeatedly rearranges components to reduce that cost. The slightest design change can completely change the start position, so this procedure can fail to find the same "minimum cost" from the same weighting factors. But a different set of weighting factors may produce a better minimum from the new start. What's missing in the PAR process is feedback from a failed routing pass about specific placement problems, back into the placer, to allow it to re-place those components, and try again. - BrianArticle: 118081
Thanks for your feedback. Yes. My data rate requirement is much higher 6.4 Gbps per channel and I have 20 channel that need to run synchronously. The issue with XAPP265 is the it will require a lot of external componets 8:1 serializer and 1:8 deserializer along with 3.2/6.4 GHz clock alignment challenges. But all this is integrated inside the transceivers. This is why I am curious if we can leverage the FPGA transcievers for this application. For data alignment we may be able to use a precise delay element in line with the high speed tranceivers. What issues do you see in using the Transceivers? I really appreciate your feedback.Article: 118082
Ben Jones wrote: > "Peter Mendham" <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk> wrote in > message news:f01v8b$r5q$1@dux.dundee.ac.uk... >> I am working with an ML405 and trying to put together a project of my own >> that uses the plb_tft_cntlr_ref IP from the example project. I tried to >> import the IP using the "Create or Import Peripheral" wizard but it >> complains that there are a bunch of signals missing that are needed by the >> PLB. > > You don't need to do that. All you need to do is drop the plb_tft_cntlr_ref > pcore into the "pcores" directory in your project. Then (once you've closed > and re-opened the project so XPS re-reads the directory) you'll see it in > the peripheral repository and you can just add it to the project like any > other piece of IP in the library. Ben, Thanks for your response. I tried what you suggested, which got me a fair way but when I went to connect my shiny new IP up (under the "ports" display mode) things got a bit funny. In the example project there are two signals (SYS_plbClk and SYS_dcrClk) which don't appear in the ports display in my project. Despite this, I bashed on and connected up the external signals then added some lines to the UCF to match. When I attempt to generate the netlist it says: Performing Clock DRCs... This application has discovered an exceptional condition from which it cannot recover. make: *** [implementation/ppc405_0_wrapper.ngc] Error 1 That's not a good thing, right? ;) Any ideas? Thanks in advance, -- PeterArticle: 118083
"Symon" <symon_brewer@hotmail.com> wrote in message news:4624c226_3@x-privat.org... > "Daniel S." <digitalmastrmind_no_spam@hotmail.com> wrote in message > news:Ic3Vh.17620$iq5.533929@wagner.videotron.net... >> >> IOBs use current-limited output drivers for slow slew > Hi Daniel, > Can you point me to a reference for this statement? > Thanks, Syms. > Also, you might be interested in this. http://groups.google.com/group/comp.arch.fpga/browse_thread/thread/1a44fd002e26bf87/ca0581ab55b1f113?lnk=st&q=slow+slew+transistor+site%3Axilinx.com&rnum=2&hl=en#ca0581ab55b1f113 It seems the slew rate is determined, as I suspected, by controlling the slew rate at the gate of the drive transistor. The gate has significant capacitance, so adjusting how hard you drive the gate will adjust the output slew rate. I think saying the slew rate depends on 'current-limiting' is a little misleading. I reckon, EMI aside, changing the slew rate setting will have bugger all effect on the OP's system when it's in contention, assuming the contention lasts for more than few ns. HTH, Syms.Article: 118084
On Apr 17, 7:48 am, Brian Drummond <brian_drumm...@btconnect.com> wrote: > On 16 Apr 2007 15:00:55 -0700, "mmihai" <iia...@yahoo.com> wrote: > > >On Apr 16, 1:39 pm, "mmihai" <iia...@yahoo.com> wrote: > > >> [...] > >> Requirement: 10.000ns > >> Data Path Delay: 10.679ns (Levels of Logic = 4) > >Inspired by a recent thread in this newsgroup (look for "Xilinx ISE > >9.1 subject") I've tried "par" with different (default is 1) "cost > >table" values (-t option) and it seems this option helps in meeting > >the target timing. With "-t 2" I'm getting: > > >Timing summary: > >--------------- > > >Timing errors: 0 Score: 0 > > It's quite normal to get timing variations of a few percent from > (a) extremely minor changes to the design and > (b) changes to the "cost table" setting (or random seed). > > If I fail to meet timings by less than 10%, one option is to run MPPR > overnight, to place/route with 10 or more different seeds - usually at > least one makes it through timings. Failing that, if I don't want to > modify the design, I look at the best failing pass in FPGA Editor, and > often the problem is only a few absurdly badly placed components, which > I can unroute, move, then let reentrant routing take over. > > As I understand it, the placer places components apparently randomly, > then evaluates the "cost" i.e. difficulty of routing, according to a > number of factors, placing a (slightly arbitrary) cost weighting on > things like distance between related components, and congestion. Then it > repeatedly rearranges components to reduce that cost. > > The slightest design change can completely change the start position, so > this procedure can fail to find the same "minimum cost" from the same > weighting factors. But a different set of weighting factors may produce > a better minimum from the new start. > > What's missing in the PAR process is feedback from a failed routing pass > about specific placement problems, back into the placer, to allow it to > re-place those components, and try again. > > - Brian You can make up for the lack of feedback in the MPPR by doing a little manual component placement. In your case it is likely that the block RAMs are in the critical timing paths. If you take the location of the placed block RAMs from a successful PAR (one that meets timing) and add them as LOC constraints in your .ucf file (or in the source code if they are instantiated), you'll probably find that the place&route process will go better. HTH, GaborArticle: 118085
I am not permitted to share my code BUT here is what I did: My master operation was driven by a couple of IPIF slave registers. I had the tool generate a generic IPIF slave interface (one with just a few registers). I use Verilog ---> I then added these signals to the port declaration list in userlogic.v (don't forget to hook these up in main VHDL file!): PLB_Clk, PLB_Rst, M_abort, M_ABus, M_BE, M_busLock, M_compress, M_guarded, M_lockErr, M_ordered, M_priority, M_request, M_RNW, M_size, M_type, M_wrBurst, M_wrDBus, PLB_MErr, PLB_MWrDAck, PLB_MAddrAck, Note that Xilinx uses the same net names as in the PLB core connect spec input PLB_Clk; input PLB_Rst; output M_abort; output [0:C_PLB_AWIDTH-1] M_ABus; output [0:C_PLB_DWIDTH/8-1] M_BE; output M_busLock; output M_compress; output M_guarded; output M_lockErr; output M_ordered; output [0:1] M_priority; output M_request; output M_RNW; output [0:3] M_size; output [0:2] M_type; output M_wrBurst; output [0:C_PLB_DWIDTH-1] M_wrDBus; input PLB_MErr; input PLB_MWrDAck; input PLB_MAddrAck; For my application, my PLB master always wrote to memory, Most of the PLB signals could be fixed. I was always doing PLB writes (64-bit) so: assign M_priority = 2'b11; // Keep this transaction priority high assign M_busLock = 0; assign M_abort = 0; assign M_RNW = 0; assign M_BE = 8'b11111111; //We are send all 64-bits assign M_size = 4'b0; assign M_type = 3'b000; //memory transfer assign M_compress = 0; assign M_guarded = 0; assign M_ordered = 0; I drove the Address and write data buses with my own logic..... assign M_ABus = EffectiveTransferAddress; assign M_wrDBus[0:31] = TransferCount; assign M_wrDBus[32:63] = ~TransferCount; Now, when you have a PLB bus in a EDK project, a PLB arbiter is added for you. This is something that is needed whether you use IPIF or not. Now, the only thig you have to do is have a state machine to operate these PLB signals: PLB_MErr M_request PLB_MAddrAck PLB_MWrDAck These are used to talk to the arbiter and request access. These signals are for writing only! If you are doing reading you need some addition PLB signals. Look in the spec to implement you state machine. Hope this helps! It is also important that you make your first example very simple. My first implementation was logic that will fill up some RAM on the PLB bus with a number sequence. I could then look in RAM to make sure the master was working..... This may seem like a really difficult piece of logic but its not as bad as you would think. Just read the PLB spec and you'll be fine. Good Luck! LilacSkin wrote: > To build my PLB master, I only need that ports ??? > > > PLB Master n Interface > > PLB-to-Master N > > PLB_MnWrDAck > PLB_MnRdAck > PLB_MnAddrAck > PLB_MnRearbitrate > PLB_MnTimeout > > Master n-to-PLB > > Mn_request > Mn_priority(0:1) > Mn_RNW > Mn_size(0:3) > Mn_rdBurst > Mn_abort > Mn_wrBurst > Mn_ABus(0:31) > Mn_UABus(0:31) > > > PLB Slave n Interfaces > > PLB-to-slave n > > PLB_RNW > PLB_abort > PLB_wrBurst > PLB_rdBurst > PLB_masterID(0:2) > PLB_PAValid > PLB_SAValid > PLB_ABus(0:31) > PLB_UABus(0:31) > > Slave n-to-PLB PLB > > Sln_wait > Sln_AddrAck > Sln_rearbitrate > Sln_rdComp > Sln_rdDAck > Sln_wrComp > Sln_wrDAck > > Where are the ports in the IBM datasheet ? > > PLB_pendpri > PLB_penreq > PLB_reqpri > PLB_size > PLB_type > PLB_rdPrim > PLB_abort > PLB_buslocked > PLB_masterID > PLB_MSize > PLB_compress > PLB_guarded > PLB_lockerrr > PLB_MErr, > PLB_MBusy....... >Article: 118086
Right now, there isn't a good way to handle what you want, exactly. As Alan said, Accellera's 2006 std has the ability to invoke packages with generics, which would do what you want. For now, I would do one of two things: First, the package for this entity could use a constant from another package (a higher level project package) to get the sizes. BTW, whenever I create packages that have typedefs, etc for an entity, I them at the top of the same file that has the entity/arch in it. That way, if you've compiled the entity/arch, you've also compiled the package necessary to use it. I also often define a record type to hold all the generics for the entity in that package. That way handling all the generics up through the hierarchy gets easier. Higher level packages for higher level entities reference the lower level entities' packages' generic record definitions, and so on, all the way to the top. So adding a new parameter for a lower level entity means adding it only to the entity/arch/package that needs it, and to the top level where it gets set. It gets automatically plumbed through all the levels in between. The second method would be to pack the entire array into one long SLV (can be an unconstrained port). Then you can pass generics into the entity that allow you to recompose the array from the SLV (or decompose the array to drive the port). Not the prettiest solution, but it works. Hope this helps, Andy On Apr 17, 4:46 am, Alan Fitch <alan.fi...@spamtrap.com> wrote: > zhang...@gmail.com wrote: > > I want to define a type related to entity generics, like an array in > > the following codes. But It seems I have no places to put those > > subtype/type statements in the entity. I can not use package to define > > those subtype/type since there are related to entity generics. > > > Any solution or idea? > > > Thanks a lot, > > > Z > > 04/16/07 > > > =============== > > library IEEE; > > use IEEE.std_logic_1164.all; > > use IEEE.std_logic_arith.all; > > use IEEE.std_logic_unsigned.all; > > > entity ir is > > -- Here is not correct > > -- subtype MY_UNSIGNED is unsigned(EL_SIZE-1 downto 0); > > -- type MY_UNSIGNED_VECTOR is array(natural range<>) of > > MY_UNSIGNED; > > generic ( > > EL_SIZE : POSITIVE := 16; > > EL_COUNT : POSITIVE := 8 > > ); > > -- Here is not correct either > > -- subtype MY_UNSIGNED is unsigned(EL_SIZE-1 downto 0); > > -- type MY_UNSIGNED_VECTOR is array(natural range<>) of > > MY_UNSIGNED; > > port ( > > val_b : out MY_UNSIGNED_VECTOR (0 to EL_COUNT-1); > > clk_i : in std_logic > > ... > > ); > > end ir; > > Hi Z, > > you must put the declarations in a package, e.g. > > library ieee; > use ieee.std_logic_arith.all; -- prefer numeric_std, it's a standard > package mytypes is > subtype MY_UNSIGNED is unsigned(EL_SIZE-1 downto 0); > type MY_UNSIGNED_VECTOR is array(natural range<>) of MY_UNSIGNED; > > end package mytypes; > > Of course you then don't have access to the generic. So you need to > fix the generic size using a constant or the subtype itself, e.g. > > package mytypes is > constant EL_SIZE : positive := 10; > subtype MY_UNSIGNED is unsigned(EL_SIZE-1 downto 0); > type MY_UNSIGNED_VECTOR is array(natural range<>) of MY_UNSIGNED; > > end package mytypes; > > You must make the package visible in front of the entity of course, e.g. > > library mylib; > use mylib.mytypes.all; > library ieee; > ... > > entity... > > assuming you compiled the package into library 'mytypes' > > Does that help? > > In Accellera VHDL2006 you can have package generics, which would be a > neater solution - but your tools must have 2006 support. > > regards > Alan > > -- > Alan Fitch > Douloshttp://www.doulos.comArticle: 118087
Hi Peter,
"Peter Mendham" <petermendham@NOCANNEDMEAT.computing.dundee.ac.uk> wrote in
message news:f02g32$9da$1@dux.dundee.ac.uk...
>>> I am working with an ML405 and trying to put together a project of my
>>> own that uses the plb_tft_cntlr_ref IP from the example project.
>> All you need to do is drop the plb_tft_cntlr_ref pcore into the "pcores"
>> directory in your project.
> Thanks for your response. I tried what you suggested, which got me a fair
> way but when I went to connect my shiny new IP up (under the "ports"
> display mode) things got a bit funny. In the example project there are
> two signals (SYS_plbClk and SYS_dcrClk) which don't appear in the ports
> display in my project. Despite this, I bashed on and connected up the
> external signals then added some lines to the UCF to match. When I
> attempt to generate the netlist it says:
>
> Performing Clock DRCs...
>
> This application has discovered an exceptional condition from which it
> cannot recover.
> make: *** [implementation/ppc405_0_wrapper.ngc] Error 1
>
> That's not a good thing, right? ;)
Depends how much you like error messages I suppose :-)
The SYS_plbClk port on the TFT reference design needs to be connected to the
same clock as the PLB bus (which is often called sys_clk_s if you're using a
design that originated with Base System Builder). The SYS_dcrClk similarly
needs to be connected to the clock signal of the DCR bus. Neither of these
clocks should need to come from an external pin. In fact I have a feeling
that the DCR clock isn't even really a clock in the true sense of the word.
In the reference design project I saw, the DCR bus connection on the TFT
block was connected to the PowerPC processor by means of an OPB-to-DCR
bridge, for some obscure reason. You can do that, or you can hook it up to
the PowerPC's DCR master port directly. The only difference is the action
the software has to perform when accessing the TFT's control registers,
which you only need to do if you want to (a) turn the thing on and off or
(b) change the base address of the frame buffer dynamically.
Good luck,
-Ben-
Article: 118088On Apr 17, 3:07 am, "Jalen....@gmail.com" <Jalen....@gmail.com> wrote: > Hi, > > I am using the UP2 development board from Altera. I have programmed a > simple ALU in it. I have done some hardware tests on it through its > expansion slots but the results are inconsistent. To perform the > tests, I connect the expansion slots with IDE cables to a verabod in > which i have soldered many switches and LEDs. However the results were > inconsistent, sometimes I couldn't load the the values into the bus at > load at all. Other times when i load the upper bits, the lower bits > get erased. Any inputs on this? I was also thinking of interfacing it > with a control card made entirely of TTL chips. Power source is taken > from the TTL control card. Any inputs on the potential problems I > might face? Thanks! > > Jalen I'm not familiar with Altera parts or your UP2, so this is all I could think of...Make sure that all of the inputs to the Altera PLD chips are connected to a HI or LO voltage. Floating inputs can cause a CMOS chip to do wierd things. If the TTL board is sending a clock to the UP2, keep the IDE cable as short as you can. Also, on the TTL board, make sure that you have plenty of bypass caps (a 0.1uF cap per chip is OK). HTH -Dave PollumArticle: 118089
On Apr 16, 11:23 pm, "Daniel S." <digitalmastrmind_no_s...@hotmail.com> wrote: > ghel...@lycos.com wrote: > > On Apr 15, 12:33 pm, rohit20...@yahoo.com wrote: > >> Hi, > > >> I was wondering how the number 166Mhz for DDR came up? Why not say... > >> 200MHz/250MHz DDR? I am sure there is some thought process behind > >> that, could someone help me walk through? > > > Perhaps this number is how slow one can go, not how fast? If you're > > not meeting timing with your FPGA, the low frequency number could be > > important. > > > DDR does have a minimum frequency... > > The minimum operating frequency for DDR DRAMs comes from the DLL circuitry > used to capture data. My 166MHz Infineon DRAMs say the minimum operating > frequency for its DLL is 100MHz. > > The maximum operating frequency is determined by how fast the DRAM is able > to get data into or out of the active row (data) register and other control > structures with the maximum amount of pipelining enabled. Since the high-K > process used for DRAMs yields slow logic, latency cycles (intermediate > registers) pile up really fast on high-speed DRAMs. Thanks Ben & Daniel ! I think you answered my curiosity question :) -UdayArticle: 118090
I am implementing an 80000 Element Shift register to be used as a very long (1Sec) digital delay generator. (Yes, its that big). It is clocked at 80kHz. Its a very simple design, just an ordinary shifter register with 80k elements. It is being implemented in a V2Pro (Digilent XUP Board). I have simulated the design and it works OK. I am now trying to synthesize the design and it is taking a *VERY* long time. I tried to synthesize on my PC (P4 3.2GHz, 1G Ram) when I left work last night. It failed 5 hours later with an out of memory error. I am now trying on a Xeon Work station with 3GB of RAM. Any pointers on how to make this synthesize faster? What kind of machines are people using out there to synthesize large designs?Article: 118091
Ben Jones wrote: > Peter Mendham wrote: >>>> I am working with an ML405 and trying to put together a project of my >>>> own that uses the plb_tft_cntlr_ref IP from the example project. >>> All you need to do is drop the plb_tft_cntlr_ref pcore into the "pcores" >>> directory in your project. >> In the example project there are two signals (SYS_plbClk and SYS_dcrClk) >> which don't appear in the ports display in my project. >> ... When I attempt to generate the netlist it says: >> >> Performing Clock DRCs... >> This application has discovered an exceptional condition from which it >> cannot recover. >> > The SYS_plbClk port on the TFT reference design needs to be connected to the > same clock as the PLB bus ... The SYS_dcrClk similarly > needs to be connected to the clock signal of the DCR bus. I was wondering whether the non-appearance of these ports in my project was something to with the unexplained nasty error. Since these have never appeared under ports, I've never connected them up. This is a naive guess based on the fact that the error occurred whilst doing something to do with clocks. What do you think? A red herring? Is there any way to persuade the "ports" display to show these so that I know they're connected to the correct clock? > In the reference design project I saw, the DCR bus connection on the TFT > block was connected to the PowerPC processor by means of an OPB-to-DCR > bridge, for some obscure reason. You can do that, or you can hook it up to > the PowerPC's DCR master port directly. I've duplicated the reference design for now with the whole OPB/DCR bridge thing. It's good to know that you can hook up the DCR directly. I'll try that if/when I ever get the thing working. > Good luck, Thanks :| -- PeterArticle: 118092
Eli Hughes wrote:
>
> I am implementing an 80000 Element Shift register to be used as a very
> long (1Sec) digital delay generator. (Yes, its that big). It is
> clocked at 80kHz.
>
> Its a very simple design, just an ordinary shifter register with 80k
> elements. It is being implemented in a V2Pro (Digilent XUP Board).
>
> I have simulated the design and it works OK. I am now trying to
> synthesize the design and it is taking a *VERY* long time. I tried to
> synthesize on my PC (P4 3.2GHz, 1G Ram) when I left work last night. It
> failed 5 hours later with an out of memory error. I am now trying on a
> Xeon Work station with 3GB of RAM.
>
> Any pointers on how to make this synthesize faster?
>
> What kind of machines are people using out there to synthesize large
> designs?
>
Here is my Code:
module shift(Clk, SIn, SOut);
input Clk;
input SIn;
output SOut;
reg [80000:0] MyShift;
reg Out;
initial
begin
MyShift = 0;
Out=0;
end
assign SOut = Out;
always @(posedge Clk)
begin
MyShift <= MyShift<<1;
MyShift[0] <= SIn;
//This is Needed to make XST happy and not reduce the design to
//a GND net
Out <= MyShift[80000];
end
endmodule
Article: 118093"Eli Hughes" <emh203@psu.edu> wrote in message news:f02jfc$nfi$1@f04n12.cac.psu.edu... > > I am implementing an 80000 Element Shift register to be used as a very > long (1Sec) digital delay generator. (Yes, its that big). It is > clocked at 80kHz. > > Its a very simple design, just an ordinary shifter register with 80k > elements. It is being implemented in a V2Pro (Digilent XUP Board). > > I have simulated the design and it works OK. I am now trying to > synthesize the design and it is taking a *VERY* long time. I tried to > synthesize on my PC (P4 3.2GHz, 1G Ram) when I left work last night. It > failed 5 hours later with an out of memory error. I am now trying on a > Xeon Work station with 3GB of RAM. > > Any pointers on how to make this synthesize faster? > > What kind of machines are people using out there to synthesize large > designs? > At 80 kHz, it would be easy to make a shift register out of the BRAMs if you aren't interested in the intermediate results. i.e. a FIFO. Each BRAM has 18kbits. Search the Xilinx website for FIFO to see how to implement this. HTH, Syms.Article: 118094
Eli Hughes wrote: > Any pointers on how to make this synthesize faster? What about using block ram and just an index pointer? Shift-in: set current bit at index, increment index pointer, read current bit and shift it out. If the index pointer reaches some limit, reset it to 0. If you clock the FPGA with a higher frequency, then the read/write cycles are no problem with your shift clock. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 118095
"Symon" <symon_brewer@hotmail.com> wrote in message news:4624ad7e_3@x-privat.org... > "Steve" <eejju@polyu.edu.hk> wrote in message > news:1176808198.147633@nsserver1.polyu.edu.hk... >> Hi, >> >> What is the default state of the unused I/O pins for Xilinx FPGA (Spartan >> 3E)? For Altera FPGA, it can be set as input tri-stated or as output >> driving gnd, etc. Is there any counterpart operation in Xilinx ISE to >> set the unused I/O pins? >> >> Thanks, >> JJ >> > Google this. > unused I/O pins site:xilinx.com > > HTH, Syms. And a little bit more helpfully, in the P&R tools under 'Generate Programming File' there an option called Unused IOB pins. You can set it to Pull Up, Pull Down or Float. HTH, Syms.Article: 118096
Jonathan Bromley <jonathan.bromley@MYCOMPANY.com> writes: > On 16 Apr 2007 01:56:48 -0700, > ashasravanthi@gmail.com wrote: > >>hi all, >> can anyone tell me where i can get a free vpw/pwm controller >>either in vhdl or verilog according to j1850 standards. > > Sounds like we don't know what "j1850" is. Could you point > us at a reference somewhere? > J1850 is an automotive comms bus, a bit like CAN, but (usuallY) only with one wire and a simple physical layer (single pull-up transistor per node): http://www.interfacebus.com/Automotive_SAE_J1850_Bus.html I guess the OP wants to do access the engine diagnostics. To my mind this is much more of a microcontroller task than an FPGA one - it's all very slow! I bet you could use a Picoblazeo to bitbash it if you put your mind to it though :-) Cheers, Martin -- martin.j.thompson@trw.com TRW Conekt - Consultancy in Engineering, Knowledge and Technology http://www.conekt.net/electronics.htmlArticle: 118097
Eli Hughes wrote: > always @(posedge Clk) > begin > MyShift <= MyShift<<1; > MyShift[0] <= SIn; > //This is Needed to make XST happy and not reduce the design to > //a GND net > Out <= MyShift[80000]; > end I don't know much about Verilog, but if you can use an index into the MyShift register instead of actually shifting it, maybe your synthesize program can infer a block ram automaticly. -- Frank Buss, fb@frank-buss.de http://www.frank-buss.de, http://www.it4-systems.deArticle: 118098
Eli Hughes <emh203@psu.edu> writes: > I am implementing an 80000 Element Shift register to be used as a > very long (1Sec) digital delay generator. (Yes, its that big). It > is clocked at 80kHz. At 80kHz you could probably get a 17-bit binary counter running. If not you can use linear feedback shift register. 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: 118099
Hi Peter,
>> The SYS_plbClk port on the TFT reference design needs to be connected to
>> the same clock as the PLB bus ... The SYS_dcrClk similarly
>> needs to be connected to the clock signal of the DCR bus.
>
> I was wondering whether the non-appearance of these ports in my project
> was something to with the unexplained nasty error. Since these have never
> appeared under ports, I've never connected them up. This is a naive guess
> based on the fact that the error occurred whilst doing something to do
> with clocks. What do you think? A red herring? Is there any way to
> persuade the "ports" display to show these so that I know they're
> connected to the correct clock?
The EDK ports view has a "filter" setting which usually hides all the nets
which have default connections. If the ports are hidden then that probably
means they've been connected up already. Signals identified as clocks in the
IP's MPD file are given special treatment, and when they're also identified
as belonging to a bus interface, the tools should automatically hook them up
to the appropriate clock source.
The filter settings are accessible via some sort of mouse-click near the top
of the ports view; can't remember exactly what the button looks like and I
think it varies from EDK version to EDK version, but it's definitely there.
Cheers,
-Ben-
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