Custom Search
Site Home Archive Home FAQ Home How to search the Archive How to Navigate the Archive
Compare FPGA features and resources
Threads starting:
Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z
On Apr 21, 7:35 pm, John_H <newsgr...@johnhandwork.com> wrote: > Michael wrote: > > > John - unless I'm missing something here... I think just watching > > edges is good enough to deal with any sort of debouncing problems, as > > long as only A or B (not both) are bouncing at any given time. > > > But either way - right now I really just want to figure out why I > > can't get the stupid thing to map properly - and then I will worry > > more about dealing with the small things. I just posted the full code, > > constraints, and console output on the FPGA4Fun forum: > >http://www.fpga4fun.com/forum/viewtopic.php?t=1281 > > > Can somebody please look at this? I just am at a complete loss as to > > what is wrong - but to you more experienced people the problem will > > probably jump right out. > > > Thanks! > > > -Michael > > What does your trim report say about the trimmed signals? > > From your mapper output you posted on FPGA4Fun, "See the trim report > for details about why the input signal will become undriven." > > - John_H Hi John - I couldn't figure out how to look at the trim report. There wasn't a single file with trim in it in the project directory. I GREPed the directory for trim and didn't turn up anything except for places where it says to look at the trim report. I googled and couldn't find anything, and I checked the Xilinx website for information about how to look at the trim report and couldn't find anything. Any suggestion as to where I can find this report? Thanks! -MichaelArticle: 131451
> >MIG creates a wrapper for the memory code. You don't need to >route the reset input to a pin of the FPGA. Most designs just >use a simple startup circuit (a few flip-flops initialized >to 1 during config in a shift-register configuration) unless >the FPGA needs to wait for some external event to start up. What you say makes sense and seems to agree with the signal description in the MIG User Guide. I'm still curious as to why MIG assigned the signal to an FPGA I/O pin. Maybe there was some option I got wrong when running MIG. Thanks for your response!Article: 131452
In article <NX0Pj.1534$26.605@newssvr23.news.prodigy.net>, notthisjoergsch@removethispacbell.net says... > krw wrote: > > In article <6PQOj.21063$%41.8783@nlpi064.nbdc.sbc.com>, > > notthisjoergsch@removethispacbell.net says... > >> John Larkin wrote: > >>> On Sun, 20 Apr 2008 14:13:21 -0700, Joerg > >>> <notthisjoergsch@removethispacbell.net> wrote: > >>> > >>>> John Larkin wrote: > >>>>> On Sat, 19 Apr 2008 14:17:44 -0700, Joerg > >>>>> <notthisjoergsch@removethispacbell.net> wrote: > >>>>> > >>>>>> Nico Coesel wrote: > >>>>>>> Dave <dhschetz@gmail.com> wrote: > >>>>>>> > >>>>>>>> Does anybody out there have a good methodology for determining your > >>>>>>>> optimal FPGA pinouts, for making PCB layouts nice, pretty, and clean? > >>>>>>>> The brute force method is fairly maddening. I'd be curious to hear if > >>>>>>>> anybody has any 'tricks of the trade' here. > >>>>>>> I start thinking about how the PCB should be routed the minute I start > >>>>>>> to draw a schematic. I always draw components with their actual > >>>>>>> pin-outs. This helps to group pins together and it helps to > >>>>>>> troubleshoot the circuit when the prototype is on your bench (no need > >>>>>>> to lookup the pinouts because they are in your diagram). > >>>>>>> > >>>>>> For quad opamps like the LM324 as well? That can make a schematic harder > >>>>>> to read and will also cause a nightmare if the layouter wants to swap > >>>>>> amp A with amp C and stuff like that. > >>>>>> > >>>>>> [...] > >>>>> A quad opamp doesn't have 1738 pins! > >>>>> > >>>> Well, yes, I was just wondering about whether Nico really always draws > >>>> the physical package. Looks like he doesn't for smaller stuff. > >>>> > >>>> With 1738 pins you can only hope that the FPGA has enough routing > >>>> resources. That used to be a major pain in the early 90's. Don't know > >>>> about nowadays since other guys design the parts with the big FPGAs. And > >>>> I am glad I don't have to deal with BGA, at least not with large ones ... > >>> The biggest ones we use are Sparten 3's with 456 balls on 1 mm > >>> centers. We haven't had any routing problems so far, doing pretty > >>> complex stuff at 128 MHz clock rates. Our in-house BGA soldering > >>> yield, to date, is exactly 100%. BGAs seem to be a lot easier to > >>> solder reliably than fine-pitch leaded parts. Easier to inspect, too, > >>> since you can't inspect them at all. > >>> > >> The latter is a concern in my field (medical). We need to be able to > >> inspect. The other concern is involuntary board flexing. Most of my > >> designs have to sustain under tortures such as freighter pilots > >> ploughing through a storm in the Carribean in airplanes as old as a DC-3 > >> or a trucker in Africa who is lead-footing it over a few hundred miles > >> of washboard road. > >> > > X-Rays? > > > > They tend not to penetrate through metal so well and are frowned upon at > the work place. But that's how it's done. -- KeithArticle: 131453
In article <dj0q04d5je4tjvlvd8if4ng2dka9159if4@4ax.com>, jjlarkin@highNOTlandTHIStechnologyPART.com says... > On Mon, 21 Apr 2008 10:04:21 -0700, "Joel Koltner" > <zapwireDASHgroups@yahoo.com> wrote: > > >"John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message > >news:coen041brmqf342022figkpv9ogjol2h0i@4ax.com... > >> Easier to inspect, too, > >> since you can't inspect them at all. > > > >I'm sure you know this, but plenty of places will X-ray BGAs to "inspect" > >them. > > > > Yes, but that's expensive and it's not usually done on a production > basis. We do have a video prism thing the lets us peek under the chip, > with fair visibility three or maybe four balls in. But we don't > routinely use it. The BGAs just work. Right. Flip-chip mounting of chips to substrates has been done for at least forty years. It just works. -- KeithArticle: 131454
Hi Goran,
Yes I realised over the weekend. So the verdict based on
experiment is...based on the system.mhs mentioned above, if you wanted
to:
1) write to peripheral 1=> use putfsl(val,0)
read from peripheral 1 => use getfsl(val,0)
2) write to peripheral 2=> use putfsl(val,1)
read from peripheral 2 => use getfsl(val,1)
So in short, I have figured out how to get it working.
the only thing is that when I had only peripheral 1 attached,
write to peripheral 1=> use putfsl(val,0)
read from peripheral 1 => use getfsl(val,1)
seems to work with the following system.mhs description:
BEGIN microblaze
PARAMETER INSTANCE = microblaze_0
PARAMETER HW_VER = 4.00.a
PARAMETER C_DEBUG_ENABLED = 1
PARAMETER C_NUMBER_OF_PC_BRK = 2
PARAMETER C_NUMBER_OF_RD_ADDR_BRK = 1
PARAMETER C_NUMBER_OF_WR_ADDR_BRK = 1
PARAMETER C_FSL_LINKS = 2
PARAMETER C_USE_FPU = 1
BUS_INTERFACE DLMB = dlmb
BUS_INTERFACE ILMB = ilmb
BUS_INTERFACE DOPB = mb_opb
BUS_INTERFACE IOPB = mb_opb
BUS_INTERFACE SFSL0 = peripheral1_to_microblaze_0
BUS_INTERFACE MFSL0 = microblaze_0_to_peripheral1
PORT CLK = sys_clk_s
PORT DBG_CAPTURE = DBG_CAPTURE_s
PORT DBG_CLK = DBG_CLK_s
PORT DBG_REG_EN = DBG_REG_EN_s
PORT DBG_TDI = DBG_TDI_s
PORT DBG_TDO = DBG_TDO_s
PORT DBG_UPDATE = DBG_UPDATE_s
END
I had verified its functionality after downloading it onto the FPGA.
I am using EDK9.1i
and I still do not have the parameters XPAR_FSL* such as
XPAR_FSL_PERIPHERAL1_OUTPUT_SLOT_ID
mentioned in the xparameters.h. I have still no idea how to get it
there.
thanks all for your inputs :)
Chris
Article: 131455krw wrote: > In article <NX0Pj.1534$26.605@newssvr23.news.prodigy.net>, > notthisjoergsch@removethispacbell.net says... >> krw wrote: >>> In article <6PQOj.21063$%41.8783@nlpi064.nbdc.sbc.com>, >>> notthisjoergsch@removethispacbell.net says... >>>> John Larkin wrote: >>>>> On Sun, 20 Apr 2008 14:13:21 -0700, Joerg >>>>> <notthisjoergsch@removethispacbell.net> wrote: >>>>> >>>>>> John Larkin wrote: >>>>>>> On Sat, 19 Apr 2008 14:17:44 -0700, Joerg >>>>>>> <notthisjoergsch@removethispacbell.net> wrote: >>>>>>> >>>>>>>> Nico Coesel wrote: >>>>>>>>> Dave <dhschetz@gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Does anybody out there have a good methodology for determining your >>>>>>>>>> optimal FPGA pinouts, for making PCB layouts nice, pretty, and clean? >>>>>>>>>> The brute force method is fairly maddening. I'd be curious to hear if >>>>>>>>>> anybody has any 'tricks of the trade' here. >>>>>>>>> I start thinking about how the PCB should be routed the minute I start >>>>>>>>> to draw a schematic. I always draw components with their actual >>>>>>>>> pin-outs. This helps to group pins together and it helps to >>>>>>>>> troubleshoot the circuit when the prototype is on your bench (no need >>>>>>>>> to lookup the pinouts because they are in your diagram). >>>>>>>>> >>>>>>>> For quad opamps like the LM324 as well? That can make a schematic harder >>>>>>>> to read and will also cause a nightmare if the layouter wants to swap >>>>>>>> amp A with amp C and stuff like that. >>>>>>>> >>>>>>>> [...] >>>>>>> A quad opamp doesn't have 1738 pins! >>>>>>> >>>>>> Well, yes, I was just wondering about whether Nico really always draws >>>>>> the physical package. Looks like he doesn't for smaller stuff. >>>>>> >>>>>> With 1738 pins you can only hope that the FPGA has enough routing >>>>>> resources. That used to be a major pain in the early 90's. Don't know >>>>>> about nowadays since other guys design the parts with the big FPGAs. And >>>>>> I am glad I don't have to deal with BGA, at least not with large ones ... >>>>> The biggest ones we use are Sparten 3's with 456 balls on 1 mm >>>>> centers. We haven't had any routing problems so far, doing pretty >>>>> complex stuff at 128 MHz clock rates. Our in-house BGA soldering >>>>> yield, to date, is exactly 100%. BGAs seem to be a lot easier to >>>>> solder reliably than fine-pitch leaded parts. Easier to inspect, too, >>>>> since you can't inspect them at all. >>>>> >>>> The latter is a concern in my field (medical). We need to be able to >>>> inspect. The other concern is involuntary board flexing. Most of my >>>> designs have to sustain under tortures such as freighter pilots >>>> ploughing through a storm in the Carribean in airplanes as old as a DC-3 >>>> or a trucker in Africa who is lead-footing it over a few hundred miles >>>> of washboard road. >>>> >>> X-Rays? >>> >> They tend not to penetrate through metal so well and are frowned upon at >> the work place. > > But that's how it's done. > Well, what else can they do? And I guess OSHA is going to be breathing down their backs all the time. I like to see things so I prefer QFP. of course you won't get 1700 pins that way but usually that's not realy needed. -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.Article: 131456
krw wrote: > In article <dj0q04d5je4tjvlvd8if4ng2dka9159if4@4ax.com>, > jjlarkin@highNOTlandTHIStechnologyPART.com says... >> On Mon, 21 Apr 2008 10:04:21 -0700, "Joel Koltner" >> <zapwireDASHgroups@yahoo.com> wrote: >> >>> "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message >>> news:coen041brmqf342022figkpv9ogjol2h0i@4ax.com... >>>> Easier to inspect, too, >>>> since you can't inspect them at all. >>> I'm sure you know this, but plenty of places will X-ray BGAs to "inspect" >>> them. >>> >> Yes, but that's expensive and it's not usually done on a production >> basis. We do have a video prism thing the lets us peek under the chip, >> with fair visibility three or maybe four balls in. But we don't >> routinely use it. The BGAs just work. > > Right. Flip-chip mounting of chips to substrates has been done for > at least forty years. It just works. > Yes, and I've done my fair share as well. But: It was either to a hard substrate that does not flex such as alumina or to a very flexible material such as Kapton. FR4 ain't my kind of turf with BGA. Can be ok for gear that doesn't get stressed much but not in my field of work. -- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.Article: 131457
Indeed some deviation from the recommended. corrected now. Main culprit was however QII requires a "signal" "variables" won't infer memory ! few more tweaks and is working. tks. lc KJ wrote: > On Apr 21, 8:41 am, LC <cupidoREM...@mail.ua.pt> wrote: >> Hi, >> >> On some pretty obvious piece of VHDL (below) >> QuartusII does not inferred any RAM !!!!!! >> (whatever "width" value is...) >> > > You didn't quite follow the template for inferring memory. > >> Any help how to convince QII to use >> RAM and not LEs ??? >> (all ram options are set to ON... >> and I've seen it working well on other occasions >> so what Is wrong here ?) >> >> many tks. >> >> lc. >> >> (I used QII7.0web ed.) >> --snip-- >> >> type k_ram_type is array (0 to (2**width)-1) >> of std_logic_vector(17 downto 0); >> shared variable k_ram: k_ram_type; >> >> begin >> >> process(a_clk) >> begin >> if rising_edge(a_clk) then >> if en_A='1' then >> if wr_en_A='1' then >> data_A_out <= k_ram(conv_integer(a_adr)); >> k_ram(conv_integer(a_adr)) := data_A_in; >> else >> data_A_out <= k_ram(conv_integer(a_adr)); >> end if; >> end if; >> end if; >> end process; >> >> --snip-- > > Remove the "if en_A='1' then " and the corresponding "end if". You > can't have a clock enable on the 'read' side. Refer back to the > Quartus documentation for the supported templates that infer memory. > > Kevin JenningsArticle: 131458
In article <5HaPj.9139$V14.611@nlpi070.nbdc.sbc.com>, notthisjoergsch@removethispacbell.net says... > krw wrote: > > In article <NX0Pj.1534$26.605@newssvr23.news.prodigy.net>, > > notthisjoergsch@removethispacbell.net says... > >> krw wrote: > >>> In article <6PQOj.21063$%41.8783@nlpi064.nbdc.sbc.com>, > >>> notthisjoergsch@removethispacbell.net says... > >>>> John Larkin wrote: > >>>>> On Sun, 20 Apr 2008 14:13:21 -0700, Joerg > >>>>> <notthisjoergsch@removethispacbell.net> wrote: > >>>>> > >>>>>> John Larkin wrote: > >>>>>>> On Sat, 19 Apr 2008 14:17:44 -0700, Joerg > >>>>>>> <notthisjoergsch@removethispacbell.net> wrote: > >>>>>>> > >>>>>>>> Nico Coesel wrote: > >>>>>>>>> Dave <dhschetz@gmail.com> wrote: > >>>>>>>>> > >>>>>>>>>> Does anybody out there have a good methodology for determining your > >>>>>>>>>> optimal FPGA pinouts, for making PCB layouts nice, pretty, and clean? > >>>>>>>>>> The brute force method is fairly maddening. I'd be curious to hear if > >>>>>>>>>> anybody has any 'tricks of the trade' here. > >>>>>>>>> I start thinking about how the PCB should be routed the minute I start > >>>>>>>>> to draw a schematic. I always draw components with their actual > >>>>>>>>> pin-outs. This helps to group pins together and it helps to > >>>>>>>>> troubleshoot the circuit when the prototype is on your bench (no need > >>>>>>>>> to lookup the pinouts because they are in your diagram). > >>>>>>>>> > >>>>>>>> For quad opamps like the LM324 as well? That can make a schematic harder > >>>>>>>> to read and will also cause a nightmare if the layouter wants to swap > >>>>>>>> amp A with amp C and stuff like that. > >>>>>>>> > >>>>>>>> [...] > >>>>>>> A quad opamp doesn't have 1738 pins! > >>>>>>> > >>>>>> Well, yes, I was just wondering about whether Nico really always draws > >>>>>> the physical package. Looks like he doesn't for smaller stuff. > >>>>>> > >>>>>> With 1738 pins you can only hope that the FPGA has enough routing > >>>>>> resources. That used to be a major pain in the early 90's. Don't know > >>>>>> about nowadays since other guys design the parts with the big FPGAs. And > >>>>>> I am glad I don't have to deal with BGA, at least not with large ones ... > >>>>> The biggest ones we use are Sparten 3's with 456 balls on 1 mm > >>>>> centers. We haven't had any routing problems so far, doing pretty > >>>>> complex stuff at 128 MHz clock rates. Our in-house BGA soldering > >>>>> yield, to date, is exactly 100%. BGAs seem to be a lot easier to > >>>>> solder reliably than fine-pitch leaded parts. Easier to inspect, too, > >>>>> since you can't inspect them at all. > >>>>> > >>>> The latter is a concern in my field (medical). We need to be able to > >>>> inspect. The other concern is involuntary board flexing. Most of my > >>>> designs have to sustain under tortures such as freighter pilots > >>>> ploughing through a storm in the Carribean in airplanes as old as a DC-3 > >>>> or a trucker in Africa who is lead-footing it over a few hundred miles > >>>> of washboard road. > >>>> > >>> X-Rays? > >>> > >> They tend not to penetrate through metal so well and are frowned upon at > >> the work place. > > > > But that's how it's done. > > > > Well, what else can they do? And I guess OSHA is going to be breathing > down their backs all the time. I like to see things so I prefer QFP. of > course you won't get 1700 pins that way but usually that's not realy needed. Your "usually" and mine are quite different. ;-) -- KeithArticle: 131459
Apparently no shared variables and not also local variables... No variables of any kind seem to be supported for ram insertion. works fine with a "signal" tks. lc. ALuPin@web.de wrote: > Are you sure that Quartus supports shared variables for RAM insertion ?Article: 131460
In article <DJaPj.9140$V14.3026@nlpi070.nbdc.sbc.com>, notthisjoergsch@removethispacbell.net says... > krw wrote: > > In article <dj0q04d5je4tjvlvd8if4ng2dka9159if4@4ax.com>, > > jjlarkin@highNOTlandTHIStechnologyPART.com says... > >> On Mon, 21 Apr 2008 10:04:21 -0700, "Joel Koltner" > >> <zapwireDASHgroups@yahoo.com> wrote: > >> > >>> "John Larkin" <jjlarkin@highNOTlandTHIStechnologyPART.com> wrote in message > >>> news:coen041brmqf342022figkpv9ogjol2h0i@4ax.com... > >>>> Easier to inspect, too, > >>>> since you can't inspect them at all. > >>> I'm sure you know this, but plenty of places will X-ray BGAs to "inspect" > >>> them. > >>> > >> Yes, but that's expensive and it's not usually done on a production > >> basis. We do have a video prism thing the lets us peek under the chip, > >> with fair visibility three or maybe four balls in. But we don't > >> routinely use it. The BGAs just work. > > > > Right. Flip-chip mounting of chips to substrates has been done for > > at least forty years. It just works. > > > > Yes, and I've done my fair share as well. But: It was either to a hard > substrate that does not flex such as alumina or to a very flexible > material such as Kapton. FR4 ain't my kind of turf with BGA. Can be ok > for gear that doesn't get stressed much but not in my field of work. They've been flip-chip mounting on organic substrates for at least a decade, too. -- KeithArticle: 131461
Peter Alfke wrote: > Well, this is a challenge. > > I am working on a design that uses 4 LUTs and 4 flip-flops, > takes in raw A and B inputs plus a clock > and outputs synchronously decoded CE and U/D signals to control a > binary counter. > There are 3 configuration options: 1, 2, or 4 counts per 360 degree > contact cycle. > And bounce is suppressed, and kept away from the counter :-) > > "Everything you always wanted to have in a quadrature detector'" Hmmm, Can you explain how bounce can be suppressed in a 4 count design ? There, you cannot distinguish between a change in direction, and a contact bounce, as they have the same signature ?. Does it also catch false/illegal states in the 4 count mode ? I have heard of very high apparent edge rates in mechanical systems, caused by shock propogations (certainly enough to stress a Software Solution) - so a 50MHz+ clock is not as silly as it may sound :) - Jim Granville,Article: 131462
Subject board has two 2C devices and a 3C device in a serial config chain. The 2C device's MSEL pins are jumper configurable to
AS (for "self-config") or PS ("Software Config") config mode. The other two FPGAs, downstream from the first 2C device, are
strapped for PS mode only.
A MAX-II CPLD sits on the DCLK, DATA0, nCONFIG, nSTATUS, nCE, nCEO, and CONF_DONE signals to "monitor" configuration in
"Self-Config" mode, and to control (drive) these signals in "Software Config" mode.
When powering up with the jumper set to "Self-Config" - where the FPGAs self-config from an EPCS64 serial config ROM - the FPGAs
config just fine (note: the first device in the serial chain, a 2C5, is the AS mode config controller).
When powering up with the jumper set to "Software Config" (i.e. MAX-II CPLD driving the configuration lines under SW control), the
FPGAs do not come alive. The nCEO outputs from each of the three FPGAs is asserted LOW, which I interpret to be solid evidence
that the FPGAs are all "configured", but CONF_DONE never goes high. And yes, we send lot and lots of extra config clock pulses to
move the devices from "configured" to "user mode". Still no CONF_DONE. But wait, there's more...
I can power up the board with the jumper set to "Self-Config" (as above), and the FPGAs configure and "come alive" (i.e. they
respond to bus accesses) as expected. Then I move the jumper to "Software Config", hit the "RESET" switch (which "warm boots" the
board without cycling power), and the FPGAs then configure under software/LOBO control at every config clock speed I've tried up
to 33.33MHz.
So what gives? Why does PS config *not* work without first configuring via AS mode? Why doesn't PS fail (or succeed) *all* the
time, given that the logic and config code doesn't change?
It sure looks like I'm lurking in the dark corners of some unwritten spec sheet that would express all the "other" requirements
for successful config. I'm not hopeful that Altera will be forthcoming with support on this one.
What "state" is cleared or changed by the AS mode config to then allow the device chain to successfully config in PS mode ?
Boy, I could sure use a life-line on this one. If anyone has some WAGs, I'm listening !
- Bob Elkind
Article: 131463Hi, I'm using a Xilinx Virtex-II Pro FPGA on a self-designed PCB and I'd like to ask for a way to program the embedded PowerPC independently from booting the whole FPGA via the Xilinx Platform Flash. Is there a way to account for that, maybe be designing an additional Flash device in the BS chain? Is it even possible to run the PowerPC even though the FPGA is not programmed? Regards JoeArticle: 131464
No, becuase you need to program the FPGA to at least form the memory and bus(es) for the processor to work. You don'y have to use flash, you can program an FPGA many ways. Xilinx has a document covering configuration options. ---Matthew Hicks > Hi, > > I'm using a Xilinx Virtex-II Pro FPGA on a self-designed PCB and I'd > like to ask for a way to program the embedded PowerPC independently > from booting the whole FPGA via the Xilinx Platform Flash. Is there a > way to account for that, maybe be designing an additional Flash device > in the BS chain? Is it even possible to run the PowerPC even though > the FPGA is not programmed? > > Regards > JoeArticle: 131465
On Apr 21, 10:12=A0pm, Kevin Neilson <kevin_neil...@removethiscomcast.net> wrote: > Haile Yu (Harry) wrote: > > Dear all, > > > I've designed a macro, and put "ring.nmc" file in my project dir. > > In my verilog module file, I wrote > > ... > > ring r1(.en(en),.ro(ro)); > > ... > > to instantiate ring macro, but failed. > > > Any one could give some hint? > > > Thank you! > > If this is a ring oscillator, you may be having problems with the tools > stripping away the logic. =A0-Kevin Hi, Kevin is right, also I use macros: declared as black box and write their "portlist followed by endmodule " in a "macro_name.v" file in the working directory. Hope this helps, /MHArticle: 131466
>On Apr 21, 4:34 pm, "jjlind...@hotmail.com" <jjlind...@hotmail.com> >wrote: >> Hello, I have a question about instantiating a module in a verilog >> testbench. Sometimes the instantiation may have lots of inputs and >> output that you may not want to appear in the ModelSim simulation, is >> there a way to stimulate particular signals in a module so the >> simulation won't include (display) all of the i/o in your design. This is probably not the most appropriate forum for this question. Try http://forums.mugweb.org/ instead.Article: 131467
<jjlindula@hotmail.com> wrote in message news:7c110d97-7eaa-440e-a661-225a0fd05de2@f36g2000hsa.googlegroups.com... ..snip > ); > Here only a few signals would be stimulated and few signals would > appear in the ModelSim simulation window. Is there a way to do this? I probably don't understand you question but you can simply drag and drop the signals of interest from the Objects window onto the Waveform window. If you want to do this from a script than look up the "add wave" command in the reference manual. Hans. www.ht-lab.com > > thanks, > joeArticle: 131468
"KJ" <kkjennings@sbcglobal.net> wrote in message news:4039fc88-3cab-46eb-b778-3d20001f14d6@d45g2000hsc.googlegroups.com... On Apr 21, 1:11 pm, Kevin Neilson <kevin_neil...@removethiscomcast.net> wrote: > > Yes, my son--you are quickly learning the lameness of VHDL. A number > isn't a number--sometimes it must be in single quotes, sometimes in > double quotes, and most often expressed in binary, just as the ancients > used to write. And almost never can you use a number directly, but must > convert it from one arcane type to another. -Kevin- Hide quoted text - > > >On the first day, the VHDL gods created 'integer', 'natural', etc. and >created ways to easily specify such numbers in any base, and saw that >it was good...and the VHDL gods said, go forth and use these types for >they are of my creation and they are good....but the unbelievers who >think every number will potentially be bigger than 32 bits on each and >every design that they create and the scallywags that created >std_logic_arith refused to use 'integer' and instead used >std_logic_vectors to perform arithmetic and then cursed the VHDL >language for the numerous type conversions that they themselves >brought down upon themselves.... > >KJ very good :-) Hans www.ht-lab.comArticle: 131469
On Mon, 21 Apr 2008 14:58:26 -0600, Kevin Neilson
<kevin_neilson@removethiscomcast.net> wrote:
>That's a good point. I'm always confused when someone asks me if I have
> "test vectors" for a design. No; I have a testbench. The whole
>concept of test vectors doesn't even seem to apply for any design with
>feedback. I'm having flashbacks to testbenches composed of
>simulator-specific "force" commands. -Kevin
Different concept. This is not a traditional device "test vector";
it's more of a software "test vector". The phrase "test vector" does
seem to have pressed all the wrong buttons and I've changed it on the
website, and added an explanation on the front page.
In short, these "vectors" may contain arbitrary expressions, and can
be enclosed in standard control constructs (my first posting actually
showed a simple example of both). You can therefore write arbitrary
reactive ("feedback") testbenches; it's nothing like a device test
vector.
However, those are just details. The fundamental idea behind a
"vector" is something different; it's a step up in abstraction levels.
The idea is that you don't have to worry about the details of writing
explicit multi-process timed code; no clock or reset processes, no
reader and checker processes, no driving and sampling, no pass/fail
determination, no error reporting, no process communication, and so
on. It's all wrapped up, automatically, in the "[,,] -> [,,]"
("vector") statement.
As an engineer testing your module, why would you care about any of
that stuff? It's just irrelevant busywork, because Verilog and VHDL
aren't smart enough to handle the details for you. I've expanded all
this on the front page of maia-eda.net, under "what is a vector?".
-Evan
Article: 131470> "Peter Alfke" <alfke@sbcglobal.net> wrote in message > news:6864a277-1433-452a-9918-c60c6b2c9463@u36g2000prf.googlegroups.com... > On Apr 20, 7:01 pm, chrisde...@gmail.com wrote: > > Hi Peter, > > I do not have this luxury. The core which is running at f/4 clock > > is a core originally written in Handel C and given to me as a ngc file > > and not in VHDL. The maximum synthesizable speed of this core is only > > at f/4 MHz. The core thus has to run at an f/4 clock. > > With this set of restrictions in mind, could there still be a > > solution to the reset problem? > Chris > There must be a limited number of flip-flops in that part of the > design. Just clock each of them with the fast clock, and drive CE with > the slower clock. Peter, from what Chris has said I don't think there are CE's into the core he's using. NialArticle: 131471
On Mon, 21 Apr 2008 16:46:19 -0700 (PDT), michael <generalnoone@gmail.com> wrote: >On Apr 21, 7:35 pm, John_H <newsgr...@johnhandwork.com> wrote: >> Michael wrote: >> >> What does your trim report say about the trimmed signals? >> >> From your mapper output you posted on FPGA4Fun, "See the trim report >> for details about why the input signal will become undriven." >> >> - John_H > >Hi John - I couldn't figure out how to look at the trim report. There >wasn't a single file with trim in it in the project directory. It's part of the mapper report file, *.mrp (often mydesign.mrp or map.mrp) - BrianArticle: 131472
On Mon, 21 Apr 2008 08:12:15 -0700 (PDT), axalay <axalay@gmail.com> wrote: >Hello. I have a problem with use opb_intc in my projekt >Where error? Give us a clue ... what error? If the PC ends up at the "unhandled exception" handler address, check that your interrupt vector table is on a 64K boundary. Only the top 16 bits of the interrupt vector table address is actually used in the PPC. So if your table isn't on a boundary, the PPC doesn't vector to where you think it does. - BrianArticle: 131473
LC wrote: > Indeed some deviation from the recommended. > corrected now. > > Main culprit was however QII requires a "signal" > "variables" won't infer memory ! Not true. http://home.comcast.net/~mike_treseler/block_ram.vhdArticle: 131474
On Apr 22, 2:13 am, "HT-Lab" <han...@ht-lab.com> wrote: > <jjlind...@hotmail.com> wrote in message > > news:7c110d97-7eaa-440e-a661-225a0fd05de2@f36g2000hsa.googlegroups.com... > > ..snip > > > ); > > Here only a few signals would be stimulated and few signals would > > appear in the ModelSim simulation window. Is there a way to do this? > > I probably don't understand you question but you can simply drag and drop > the signals of interest from the Objects window onto the Waveform window. If > you want to do this from a script than look up the "add wave" command in the > reference manual. > > Hans.www.ht-lab.com > > > > > thanks, > > joe Hello, thanks for responding to my post. Sorry for me confusing everyone. Let's say I have a large design that has lots of inputs and outputs and let's say I'm only interested in a simulation consisting of only a few inputs and outputs. When I run ModelSim it will add in all the inputs/output of the module I am simulating, thus adding in all of the inputs and outputs of my design into the waveform window. I was hoping I could configure something so when the simulation finishes it would display the signals I'm interested in. Is that possible? I'll also try the other newsgroup and see if anyone has a solution. thanks, joe
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