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
I've searched a little more and found that if I can somehow merge Ben Cohen's 0 ohm device (http://groups.google.com/group/comp.lang.vhdl/msg/7d14832588a0cabb) with a bi-directional MUX (http://www.tek-tips.com/viewthread.cfm?qid=1188582&page=7), then I might be able to create the VHDL module I would need. The bus splitting doesn't need a module, since in VHDL I'll just manipulate bit0 of the inputted flash data bus and pass the other 7 bits through. Would this work? Thanks. Matt >The MISO and data<0> signals are bidirectional (IO). Can you make a >mux/switcher and bus splitter for bidirectional signals? > >Matt > >>"mstanisz" <matt.staniszewski@gmail.com> wrote in message >>news:19mdndgAN665R2LUnZ2dnUVZ_qadnZ2d@giganews.com... >>> Okay, I went ahead and removed the duplicate NETs in the UCF and made >them >>> internal. I'm trying to figure out how to MUX between the two signals >>> using a core in EDK. It does seem like it should be fairly simple, but > >>> I'm >>> not sure how to go about it with IP cores. Thanks. >> >>Minimally, define a module with OUT pins for the two now disconnected >nets, >>additional pins for selection, and an IN pin for the external net. Add >the >>external net to the UCF. This is exactly as you would do for any old >simple >>design. There might already be an example or usable hdl in the samples >files >>for that board. >> >>My normal workflow wraps the EDK project in an ISE project. Instantiate >the >>switcher/mux in the top most module, at the same level you instantiate >the >>EDK system. Swap and mix the pins as you need. Take a look at (for a >project >>named system.xmp) hdl/system_stub.vhd for an example of instantiating the > >>EDK system. >> >>I think it would be a bad idea to tear into the pcore hdl or wrappers to >do >>this. >> >> >Article: 140251
Can someone explain the following behaviour? 1. Running MPPR to find the optimal seed number par -n 0 -pl high -rl std -t 2 cufc_top_map.ncd results.dir cufc_top.pcf Level/ Design Timing Number Run NCD Cost [ncd] Score Score Unrouted Time Status ---------- ------ -------- -------- ----- ------------ H_S_36 * 2269 302 0 33:09 Complete H_S_26 * 4271 496 0 37:41 Complete etc... 2. Running PAR with the found seed number par -pl high -rl std -t 36 cufc_top_map.ncd cufc_top_par cufc_top.pcf Timing Score: 243686 /MikhailArticle: 140252
On May 6, 12:42=A0am, "mstanisz" <matt.staniszew...@gmail.com> wrote: > I've searched a little more and found that if I can somehow merge Ben > Cohen's 0 ohm device > (http://groups.google.com/group/comp.lang.vhdl/msg/7d14832588a0cabb) with > a > bi-directional MUX > (http://www.tek-tips.com/viewthread.cfm?qid=3D1188582&page=3D7), then I m= ight > be able to create the VHDL module I would need. =A0The bus splitting > doesn't > need a module, since in VHDL I'll just manipulate bit0 of the inputted > flash data bus and pass the other 7 bits through. =A0Would this work? > Thanks. > > Matt > > > > > > >The MISO and data<0> signals are bidirectional (IO). =A0Can you make a > >mux/switcher and bus splitter for bidirectional signals? > > >Matt > > >>"mstanisz" <matt.staniszew...@gmail.com> wrote in message > >>news:19mdndgAN665R2LUnZ2dnUVZ_qadnZ2d@giganews.com... > >>> Okay, I went ahead and removed the duplicate NETs in the UCF and made > >them > >>> internal. =A0I'm trying to figure out how to MUX between the two > signals > >>> using a core in EDK. =A0It does seem like it should be fairly simple, > but > > >>> I'm > >>> not sure how to go about it with IP cores. =A0Thanks. > > >>Minimally, define a module with OUT pins for the two now disconnected > >nets, > >>additional pins for selection, and an IN pin for the external net. Add > >the > >>external net to the UCF. This is exactly as you would do for any old > >simple > >>design. There might already be an example or usable hdl in the samples > >files > >>for that board. > > >>My normal workflow wraps the EDK project in an ISE project. Instantiate > >the > >>switcher/mux in the top most module, at the same level you instantiate > >the > >>EDK system. Swap and mix the pins as you need. Take a look at (for a > >project > >>named system.xmp) hdl/system_stub.vhd for an example of instantiating > the > > >>EDK system. > > >>I think it would be a bad idea to tear into the pcore hdl or wrappers > to > >do > >>this.- Hide quoted text - > > - Show quoted text - you need own small EDK IP, that connects to xx_I xx_T xx_O busses (from the parallel flash core, you need make this bus internal) and to your signal. you need to mux using control signal, the new IP exposes the new bus to be exported takes about 30 minutes to make AnttiArticle: 140253
"mstanisz" <matt.staniszewski@gmail.com> wrote in message news:0f2dnf-i_aMyL53XnZ2dnUVZ_hqdnZ2d@giganews.com... > I've searched a little more and found that if I can somehow merge Ben > Cohen's 0 ohm device > (http://groups.google.com/group/comp.lang.vhdl/msg/7d14832588a0cabb) with > a > bi-directional MUX > (http://www.tek-tips.com/viewthread.cfm?qid=1188582&page=7), then I might > be able to create the VHDL module I would need. The bus splitting > doesn't > need a module, since in VHDL I'll just manipulate bit0 of the inputted > flash data bus and pass the other 7 bits through. Would this work? > Thanks. > > Matt You'll still need logic to figure out which personality is active. No one here is likely to write it for you, as this is a seminal moment in your learning. There's quite a bit involved, but they're all small and nothing by itself is overwhelming. Step away from the immediate problem, and take it a step at a time. Start with a basic, empty ISE project, and wire one user I/O pin for dual functions as you have in the actual problem. Setup up a testbench and play with it in simulation. The immediate problem is strictly behavioral, so it should simulate well before moving on. What are the roles of CE#, WE#, and SPI CS? Can you safely arbitrate conflicts? What effect does the additional logic have on signal timing? What are those requirements, and how do you specify them in the design? Once it's working, how will you integrate it into EDK? Antii's suggestion of a pcore you can reuse is a good one. Another way is to wrap the xmp system in an overall design, and instantiate it there. > >>The MISO and data<0> signals are bidirectional (IO). Can you make a >>mux/switcher and bus splitter for bidirectional signals? >> >>Matt >> >>>"mstanisz" <matt.staniszewski@gmail.com> wrote in message >>>news:19mdndgAN665R2LUnZ2dnUVZ_qadnZ2d@giganews.com... >>>> Okay, I went ahead and removed the duplicate NETs in the UCF and made >>them >>>> internal. I'm trying to figure out how to MUX between the two > signals >>>> using a core in EDK. It does seem like it should be fairly simple, > but >> >>>> I'm >>>> not sure how to go about it with IP cores. Thanks. >>> >>>Minimally, define a module with OUT pins for the two now disconnected >>nets, >>>additional pins for selection, and an IN pin for the external net. Add >>the >>>external net to the UCF. This is exactly as you would do for any old >>simple >>>design. There might already be an example or usable hdl in the samples >>files >>>for that board. >>> >>>My normal workflow wraps the EDK project in an ISE project. Instantiate >>the >>>switcher/mux in the top most module, at the same level you instantiate >>the >>>EDK system. Swap and mix the pins as you need. Take a look at (for a >>project >>>named system.xmp) hdl/system_stub.vhd for an example of instantiating > the >> >>>EDK system. >>> >>>I think it would be a bad idea to tear into the pcore hdl or wrappers > to >>do >>>this. >>> >>> >>Article: 140254
On Tue, 05 May 2009 16:27:20 -0500, "mstanisz" wrote: >I've searched a little more and found that if I can somehow merge Ben >Cohen's 0 ohm device >(http://groups.google.com/group/comp.lang.vhdl/msg/7d14832588a0cabb) with a >bi-directional MUX >(http://www.tek-tips.com/viewthread.cfm?qid=1188582&page=7), then I might >be able to create the VHDL module I would need. The bus splitting doesn't >need a module, since in VHDL I'll just manipulate bit0 of the inputted >flash data bus and pass the other 7 bits through. Would this work? I don't know exactly what you're trying to do, but you should be aware of these points: 1) The zero-ohm link model won't synthesise. Furthermore, it misbehaves in some corner cases that may get you, depending on what sort of logic appears at each end of the link. 2) The bidi-mux code you mention is effectively based on a bidirectional tri-state buffer on the mux I/O. This is OK, even inside an FPGA; as has been discussed here several times, the tri-states will be mapped to muxes by a synthesis tool; but you will need to be VERY careful to ensure that the direction-control bit is correctly manipulated. Given that the bidi-mux needs a proper direction control signal, I don't see what you're gaining by all this palaver. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK jonathan.bromley@MYCOMPANY.com http://www.MYCOMPANY.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 140255
> google mr16 verilog > > take first hit I tried this, but it only takes me to a copy of this thread on www.fpgarelated.com. Do you have a permanent link to the project? Best regards, MarcArticle: 140256
On Tue, 5 May 2009 02:22:44 -0700 (PDT), Nicolas Matringe wrote:
>I'm just done with this and since this a quite frequent question I
>thought I might give my solution so that the time I struggled with
>this probllem will benefit to others.
Thanks for the nice writeup. Useful!
>My time/date is a top-level generic parameter called G_DATE :
> generic (
> G_DATE : string := "00:00 00/00/00");
[...]
>and added this line:
> set current_date [clock format [clock seconds] -format "%H:%M %D"]
>which gives me the date in the format I want
>
>I then set the top-level generic parameter
> project set "Generics, Parameters" "G_DATE=\"$current_date\" "
> -process "Synthesize - XST"
>Do not put spaces around the '=' and put one space between the double
>quotes
Fascinating - why is there a need for a space after the
closing quote of the generic's value-string?
Does ISE really need that? Madness!
Also, the backslash-escaped quote characters are pretty ugly.
Could I suggest a slight modification in the interests of
clarity (with no functional change) thus:
set current_date ..... < exactly as you did >
set GDATE_with_space [format {GDATE="%s" } $current_date]
Now the literal quote characters are part of the GDATE_with_space
variable, along with the generic's name and the = symbol; so
you can now
project set {Generics, Parameters} $GDATE_with_space \
-process {Synthesize - XST}
Notes:
(1) I used braces {} to quote the operation names; that makes
it easier to include weird characters, since {} gives you
literal quoting in Tcl. Inside regular quotes "", Tcl
nevertheless performs its substitutions (it respects
[], $ and backslash). The combination of braces {} and
the "format" command often is a good way to construct
strings that contain weird characters.
(2) I used a backslash character to allow line continuation;
this is nice for commands that have lots of options, but
PLEASE NOTE that the backslash MUST be the very last
character at the end of the line.
Thanks again,
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * e * Perl * Tcl/Tk * Project Services
Doulos Ltd., 22 Market Place, Ringwood, BH24 1AW, UK
jonathan.bromley@MYCOMPANY.com
http://www.MYCOMPANY.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 140257
On May 5, 4:36=A0pm, Nicolas Matringe <nicolas.matri...@fre.fre> wrote:
> rickman a =E9crit :
>
>
>
> > I am trying to use a generic at the top level of my code to define
> > which device family the code is being compiled to. =A0In XST there is a
> > property dialog that can attach a generic property to the synthesis
> > process. =A0I am using this and not finding that it works.
>
> > In the top level code, I assign a default value to the generic which
> > is what is being used. =A0Of course, I use the same default value at
> > every level of the code. =A0If I remove the default value for the
> > generic, the tool complains that there is *no* value assigned. =A0The
> > value set as the process property shows up in the Synthesis Report
> > except that in the property dialog box the generic value is enclosed
> > in double quotes and in the report the trailing quote is missing.
> > Removing the quotes does not work either.
>
> > Am I doing something wrong here? =A0Does this generic assignment
> > function work in XST? =A0Anyone else use it?
>
> Hi Rick
> Have a look at my last post (today, subject "ISE & VHDL : how to include
> time/date")
> At least in the tcl script there must be a space between final quotes. I
> don't know how you can fix this in the GUI though
>
> Nicolas
I tried it with the quotes, I tried with various combinations of
spaces and quotes, I tried with no quotes. All gave the same
results. The Generic is ignored. If I remove the default value of
the top level generic an error says it has no value.
This is what ISE says is being passed into the code.
Generics, Parameters :
{ DEVICE_FAM=3D"FPGA_FAMILY_SPARTAN_3 }
This is what is the top level module uses...
Analyzing hierarchy for entity <Novus> in library <work> (architecture
<rtl>) with generics.
BYWTH =3D 9
DAWTH =3D 18
DEVICE_FAM =3D "fpga_family_lattice_xp"
Notice that the ending quote is always missing in the value reported
as passed into the top level.
Rick
Article: 140258The parameter being set is an enumerated type. Would that make a difference? RickArticle: 140259
On May 4, 11:33 pm, "MikeWhy" <boat042-nos...@yahoo.com> wrote: > Feeling empowered and encouraged because MXE-III 6.3c Starter was running so > well, I downloaded and installed MXE-III 6.4. It had problems compiling the > EDK 10.1sp3 libraries, aborting the experiment abruptly. Several more > iterations of failure later, sleep deprivation suggested that ModelSim PE > student version was a good idea. After all, Xilinx characterizes MXE > performance relative to PE. A search for license limitations turned up only > the need to renew the license every 6 months. Alas, I discovered very > quickly that it suffers the same 10k line limitation as MXE. It stalled at > about the 80% mark while compiling the ISE libraries. That was my weekend in > a nutshell. > > This evening, I tried in earnest to restore MXE 6.3 to working order. The > library paths, environment vars, and tools settings are a faint blur in my > mind, after a weekend of little sleep and much despair. Is there a neat > checklist somewhere of things to put back in order to get it working again? > Simulations bomb out on the Microblaze IP, complaining that the library .dat > file is incompatible. Other modules blow out on various Unisim or other > components. I've unpacked, installed, recompiled, updated, refreshed, and > basically stirred around everything that could be stirred around. I've > reinstalled the 10.1.3 ISE libraries, etc. Recmpiled the EDK libs, which > reports a varying number of errors each time. Any help would be much > appreciated. > > (I don't know if it's a bad idea or not, but 11.1 is downloading in the > background as I type this. In for a penny..., as the saying goes. I was > searching for MXE 6.4 version compatibility on the Xilinx website, when I > was presented with a download button and a page offering to create floating > licenses for my DSP stuff and EDK. Oh, what the heck. If it works, the > recent frustrations will be moot.) > > (PPS: and totally unrelated to anything at all... This afternoon, a huge > housefly noisily buzzed my monitors before landing on the window screen of > the open window in the upstairs office. Crap! I had no way to invite it > outside while preventing its escape to buzz the rest of the house. So I > closed the storm window, trapping it in the narrow space between. He was > doomed, of course, and there was no way he could know this. From his > considerable size, he obviously survived the winter, only to come to this > ignominious end. Long story short, he fought hard to the very end. Through > it all, I watched him from time to time, and waved various stuff at him to > keep him agitated and watch his response. I'm pleased and proud for him, for > never once giving in to despair or frustration. Life is like that for each > of us at one time or another, I think. My weekend sucked. I wonder this > moment if 11.1 is the hoped for open window, or just another pretty purple > plastic fly swatter. 2 hours left to go on the download...) ModelSim has a bad habit of piddling on itself. A complete un- and re- install might help. Other things to look for are (hidden) work libraries that it left behind. I have become a fan of virtual machines. VMWare is not that expensive, VirtualBox is free. It takes very little time to clone a known-good fresh system, and install the application of the moment on it. ALArticle: 140260
On May 6, 1:51=A0pm, jetm...@hotmail.com wrote: > > google mr16 verilog > > > take first hit > > I tried this, but it only takes me to a copy of this thread onwww.fpgarel= ated.com. > > Do you have a permanent link to the project? > > Best regards, > Marc http://members.at.infoseek.co.jp/x1resource/xilinx/ip/mr16/mr16.htmlArticle: 140261
Hi Rick,
I have had similar problems with the 'Generics, Parameters' under
'Synthesis Options'. I could get it to work in a simple example, but
synthesis did not react on the value for a more complex design.
But there is an alternative through the 'Other XST Command Line
Options', which is last line in the window with 'Generics,
Parameters'. You can then use the XST command line syntax, that
Jan Pech mentioned, thus '-generics {BIDIR=TRUE CHANNELS=1}'. That
worked for me.
Good luck,
Morten
Article: 140262How would the generics setting be done using xflow from a Makefile? -- SvennArticle: 140263
Hi, In order to convert from 32-bit word with to 8-bit word width, I use a dual-port ram with a 32-bit wide bus on the a-side and 8-bit bus on the b-side. This "width-converter" is used by several memories, one at a time. The memories are implemented as BRAMs, each 32-bit wide and 5 address bits deep. The "width-converter" a-side has the same depth as the BRAMs. The movement of the data from the BRAM to the dual-port RAM a-side is done by a counter that run from 0 to 2**6-1 and give the same value on BRAM address input and dual-port a-side address input. The data out of the BRAM is routed directly to the data input of the dual-port RAM. Now comes the snag that I have not really found a good solution to: Since the BRAM only expose data on its dout after a clock, the dual- port RAM will, on the same clock edge, sample the previous value of the data bus. Hence, there will always be a shift in the dual-port RAM: (dual-port)address-0 will have (BRAM)data_-1 (whatever value that is present on the data bus) (dual-port)address-1 will have (BRAM)data_0 (dual-port)address-2 will have (BRAM)data_1 and so on. I have tried to put a register between the counter and the dual-port RAM to delay the address arriving at the dual-port RAM by one cycle. When this register is always carefully set to 0 before each data transfer, dual-port ram address 0 is written twice, once with data_-1 and once with data_1 and from there on address and data are aligned until the counter stops. Then the last word is missing in the dual- port ram since I would actually need one more dummy transfer for the last address to propagate through the delay register. I just can't find the magic way to get a nice aligned data transfer between a BRAM and a dual-port RAM. Any ideas? -- SvennArticle: 140264
anyone have design raid controller experience?Article: 140265
On 2009-05-07, recoder <kurtulmehtap@gmail.com> wrote: > Hi FPGA Gurus, > I need to get a Gigabit Ethernet message, change its destination > IP,change some bits in the message(process) and send it out. I figure > out that I need 2 GigE ports to do that. I don't want to pay for the > MAC, so the board should be built with the Virtex 5 FPGAs or Altera > alternatives. One solution could be the NetFPGA board which is rather decently priced if you happen to be an academic customer. Although the FPGA used (Virtex-II Pro 50) is somewhat old now. http://www.digilentinc.com/Products/Detail.cfm?NavTop=2&NavSub=521&Prod=NETFPGA /AndreasArticle: 140266
On May 5, 8:03=A0pm, leevv <le...@mail.ru> wrote: > I've discovered recently the problem with the edge-type interrupts > under the Xilinx EDK. > I heard that it was acknowledged by Xilinx and AR will come out soon. > May be the following will be usefull for somebody. > > 1) XPS_INTC v1.00a synchronization FFs for the edge-type interrupts. > > During the upgrade of the working project from ISE/EDK9.1sp3 to =A0ISE/ > EDK10.1sp3 environment we've got a problem with the skipping > interrupts from the custom =93Interleaver=94 PCORE. > > Interrupt subsystem consist of "Interleaver" PCORE -> =A0XPS_INTC 1.00a -= > =A0PPC405_virtex4 v2.01a. > > "Interleaver" PCORE generates a regular Interrupt pulse every few > mSeconds on asynchronous (relative to XPS_INTC) clk domain. Interrupt > is configured to be a rising-edge-type interrupt. The duration of the > pulse is more then several clk periods of the XPS_INTC clk (100 MHz in > our case), as it=92s required by datasheet. > > After analysis with Chipscope it's turns out that the problem is due > to the absence of synchronization flip-flops (FFs) on the interrupt > inputs of the XPS_INTS !!! > > I was "surprised" to see the following in the "intc_core.vhd" of the > XPS_INTC pcore: > > --------------------------------------------------------------- > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Process REG_INTR_P to regiter the inte= rrupt signal > > --------------------------------------------------------------- > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 REG_INTR_P : process (Clk) is > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 begin > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if(Clk'event and Clk=3D'1') then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (Rst =3D RESET_ACTIVE)= then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 intr_d1(i) <=3D '= 1'; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 intr_d1(i) <=3D I= ntr(i); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end process REG_INTR_P; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Creating one-shot rising edge triggere= d interrupts > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 intr_edge(i) <=3D '1' when Intr(i) =3D '1= ' and intr_d1(i) > =3D '0' > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0else '= 0'; > > As you can see the =93Intr=94 signal, which is the input to the XPS_INTC > module and could be completely ASYNCHRONOUS, is involved in the edge > detection. > There is no synchronization FFs et al! Not even mentioning meta- > stability double FFs. > > I added a couple of FFs like this to the rising and falling edge > inputs of XPS_INTC like this: > > --------------------------------------------------------------- > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Process REG_INTR_P to regiter the inte= rrupt signal > > --------------------------------------------------------------- > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 REG_INTR_P : process (Clk) is > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 begin > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if(Clk'event and Clk=3D'1') then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (Rst =3D RESET_ACTIVE)= then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 intr_d1(i) <=3D '= 0'; intr_d2(i) <=3D '0'; > intr_d3(i) <=3D '0'; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 intr_d3(i) <=3D i= ntr_d2(i); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 intr_d2(i) <=3D i= ntr_d1(i); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 intr_d1(i) <=3D I= ntr(i); > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 end process REG_INTR_P; > > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -- Creating one-shot rising edge triggere= d interrupts > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0intr_edge(i) <=3D '1' when intr_d3(i) =3D = '1' and intr_d2 > (i) =3D '0' else '0'; > > Now Interleaver PCORE works fine. I still don=92t understand how our > project was working under ISE/EDK9.1. There is no synchronization FFs > either in OPB_INTC pcore. May be we were lucky (or unlucky) not to > discover it under 9.1. > > But unfortunately this is not the end of the story. > > 2) XPS_UARTLITE v.1.00a receive interrupt. > > Now other edge-type interrupt inputs, which are connected to the > XPS_INTC pcore, have a problem. In particularly the XPS_UARTLITE > pcores has a problem with the receive interrupts. In our system we > have only XPS_UARTLITE and Interleaver pcores which are using edge- > type interrupts. All the rest pcores use level-type interrupts. > In this project one XPS_UARTLITE is used as a debug console for the > Linux and another one is used for the communication with the external > peripheral (Upconverter). Both start to fail after I=92ve made the > modification to XPS_INTC. On the debug console I can see that print- > outs are working fine, while when I=92m typing something in the console > - the RX direction of the XPS_UARTLITE doesn=92t work. > > Now I was =93surprised=94 second time to discover in the datasheet that > XPS_UARTLITE generates the edge-type interrupt for the transmit part > and level-type interrupt for the receive part of the pcore. While this > is two completely different types of interrupts, they are both > signaled through one physical output signal of the XPS_UARTLITE > pcore !!! > > ------------------------------------------------------------------------- > =A0 =A0 -- Interrupt register handling > > ------------------------------------------------------------------------- > =A0 =A0 INTERRUPT_DFF: process (Clk) is > =A0 =A0 begin > =A0 =A0 =A0 =A0 if Clk'event and Clk =3D '1' then > =A0 =A0 =A0 =A0 =A0 =A0 if Reset =3D '1' then =A0 =A0 =A0 =A0 -- synchron= ous reset (active > high) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Interrupt <=3D '0'; > =A0 =A0 =A0 =A0 =A0 =A0 else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Interrupt <=3D enable_interrupts and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(rx_Data_Prese= nt or (tx_Buffer_Empty and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0not > tx_Buffer_Empty_Pre)); > =A0 =A0 =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 =A0 end if; > =A0 =A0 end process INTERRUPT_DFF; > > Here the =93rx_Data_Present=94 signal is the level-type interrupt, > indicating that Receive buffer is not empty. > I=92m not sure either the root of the problem is in the low-level > software driver, which handle the XPS_UARTLITE interrupts or something > else, but I think it=92s better to have both TX and RX interrupts to be > edge-type anyway, especially if interrupt signal from the XPS_UARTLITE > coming to the single edge-type input of the XPS_INTC. So I changed it > to be edge type, and now it works fine. > > ------------------------------------------------------------------------- > =A0 =A0 -- convert level RX interrupt to rising edge > =A0 =A0 Process (Clk) is > =A0 =A0 begin > =A0 =A0 =A0 =A0 if (Clk'event and Clk =3D '1') then > =A0 =A0 =A0 =A0 =A0 =A0 if Reset =3D '1' or enable_interrupts=3D'0' then > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rx_Data_Present_Pre <=3D '0'; > =A0 =A0 =A0 =A0 =A0 =A0 else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 rx_Data_Present_Pre <=3D rx_Data_Present; > =A0 =A0 =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 =A0 end if; > =A0 =A0 end process ; > > ------------------------------------------------------------------------- > =A0 =A0 -- Interrupt register handling > > ------------------------------------------------------------------------- > =A0 =A0 INTERRUPT_DFF: process (Clk) is > =A0 =A0 begin > =A0 =A0 =A0 =A0 if Clk'event and Clk =3D '1' then > =A0 =A0 =A0 =A0 =A0 =A0 if Reset =3D '1' then =A0 =A0 =A0 =A0 -- synchron= ous reset (active > high) > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 iInterrupt <=3D '0'; > =A0 =A0 =A0 =A0 =A0 =A0 else > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 iInterrupt <=3D enable_interrupts and > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ((rx_Data_Pre= sent =A0and not > rx_Data_Present_Pre) or > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(tx_Buffer_Emp= ty and not > tx_Buffer_Empty_Pre)); > =A0 =A0 =A0 =A0 =A0 =A0 end if; > =A0 =A0 =A0 =A0 end if; > =A0 =A0 end process INTERRUPT_DFF; > > As a conclusion. Somebody should be very careful about designing > Interrupt-related modules in a system (hardware or software). This > kind of problem potentially could cause very rare and weird > malfunctioning of the system which is very-very difficult to catch. I also found such strange behaviour. There are also some additional stuff: level detection also sucks. If your peripheral triggers level based interrupt and if the interrupt still exists afterwards then you will end up with no interrupt routine triggering. That is a problem with xps_mailbox. I could not get it to work properly. The xilinx tools are always full of bad surprises. I hope that 11.1 has less. Cheers. AlesArticle: 140267
Hi FPGA Gurus, I need to get a Gigabit Ethernet message, change its destination IP,change some bits in the message(process) and send it out. I figure out that I need 2 GigE ports to do that. I don't want to pay for the MAC, so the board should be built with the Virtex 5 FPGAs or Altera alternatives. Does a board like this exists?Article: 140268
Hi all, In all my FPGA projects I try to keep everything uniform including directory structures for projects etc, this allowing the same Modelsim VCOM command to be used throughout (ie compiling designs and testbanches to ../Modelsim/work). To stop having to compile the (usually) Altera libraries (altera_mf) into every project directory I usually have a 'central' library. Unfortunately the location of this varies depending on the machine I'm working on (main, client's, laptop). It would be really convenient to be able to declare an $Altera_Libraries environmental variable and use this in Modelsim.ini, the way the $Model_Tech one is. This could be set once for the machine then the same directories copied/revision controlled machine independantly. I've played about with this but haven't had any sucess. Has anyone got anything similar to work? Thanks for any pointers, NialArticle: 140269
Anybody has an idea?Article: 140270
Nial Stewart wrote:
> It would be really convenient to be able to declare an $Altera_Libraries
> environmental variable and use this in Modelsim.ini, the way the $Model_Tech
> one is. This could be set once for the machine then the same directories
> copied/revision controlled machine independantly.
>
> I've played about with this but haven't had any sucess.
>
> Has anyone got anything similar to work?
Yes, I haven't had any problems with that.
In my case it's Xilinx libraries, and I put them in the directory
defined by the $XILINX environment variable, wich I can use in the
modelsim.ini, so this should work for you as well.
I suspect there's a problem with the environment variable itself. I know
that in Linux/UNIX it matters in what startup script you define the
variable in. It might be that you put it in ~/.bash_profile, and that
isn't executed for non-login shells or something (I could never wrap my
head around this sort of stuff...). In Windows this should not be an issue.
I'd first check if the variable is in fact available in ModelSim. Start
ModelSim like you usually do, and check the variable ("set
env(altera_libraries)" or something). If that doesn't give you the right
value, then you need to define the variable somewhere else.
In some Linux distros you have /etc/profile.local for that kind of stuff
(variables that should be set for all users and all shells) or a
/etc/bash.bashrc that is executed for every Bash started (bur not for
ZSH or whatever else is there).
HTH,
Sean
--
Replace "MONTH" with the three-letter abbreviation of the current month
(simple, eh?).
Article: 140271recoder <kurtulmehtap@gmail.com> wrote: > I need to get a Gigabit Ethernet message, change its destination > IP,change some bits in the message(process) and send it out. I figure > out that I need 2 GigE ports to do that. I don't want to pay for the > MAC, so the board should be built with the Virtex 5 FPGAs or Altera > alternatives. > Does a board like this exists? You might post to comp.dcom.lans.ethernet and see what they say over there. I believe you need at least the PHY as external. The echo cancelation needed for gigabit is pretty complicated. -- glenArticle: 140272
recoder a couché sur son écran : > Hi FPGA Gurus, > I need to get a Gigabit Ethernet message, change its destination > IP,change some bits in the message(process) and send it out. I figure > out that I need 2 GigE ports to do that. I don't want to pay for the > MAC, so the board should be built with the Virtex 5 FPGAs or Altera > alternatives. > Does a board like this exists? I think a good solution would be to use a venerable Cyclone II Kit : http://www.altera.com/products/devkits/altera/kit-nios-2c35.html and plug two Gigabit Adapters in the SantaCruz connectors. http://www.devboards.de/shop/artikeldet.php?proid=5752&bez=DBGIG1%20V1.3&sid=b7a22203ac950ff9e4b316d03cab30a9&PHPSESSID=b7a22203ac950ff9e4b316d03cab30a9 Can be developped using the free Quartus II Web edition. We have all these items in stock if it can help, let me know. The whole system can be up & running in just a few hours. (we also have optimized GbE MAC etc) BertArticle: 140273
recoder a exprimé avec précision : > Hi FPGA Gurus, > I need to get a Gigabit Ethernet message, change its destination > IP,change some bits in the message(process) and send it out. I figure > out that I need 2 GigE ports to do that. I don't want to pay for the > MAC, so the board should be built with the Virtex 5 FPGAs or Altera > alternatives. > Does a board like this exists? Sorry for the silly question : do you absolutely need the two /independent/ adapters ? GbE is bi-directional and a swicth will route and dispatch the flows. (You can receive a flow and re-send it at full speed with one single adapter) BertArticle: 140274
Nial Stewart avait énoncé : > Has anyone got anything similar to work? Did you try this in ModelSim's cmmand windows : puts $env(QUARTUS_ROOTDIR) Bert
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