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
Dear Antti, the code is provided free of charge via email. However, no support or design guidance is guaranteed. Its use is at your own risk. So, simply fill in the form and expect a brief email conversation. ( http://www.infotech.tu-chemnitz.de/~tlau/pci_bridge/kontakt.php3 ) Cheers, Thomas -- http://www.infotech.tu-chemnitz.de/~knoll/ "Antti Lukats" <antti@case2000.com> wrote in message news:<c1di1m$vqs$00$1@news.t-online.com>... > Torsten, > > what do you mean by "Free" ? > on the link there is notice > > "if interested please contact using a form" - there is no reference to any > form or download location or conditions. > so what it is all about? > > also the website says the ref design uses Spartan III not IIE ? > > antti > www.openchip.org >Article: 66626
Jim Granville <no.spam@designtools.co.nz> wrote in message news:<RDx_b.28109$ws.3170985@news02.tsnz.net>... > "Hal Murray wrote: > >>I suspect that the difficulty for just about any home grown processor is going to be the tools to compile the > >>code for it, although folks who are more saavy than I on the software side might argue that the high speed > >>hardware design is the hard part. > > > > > > How much code are you writing? Would you be willing/happy to do it in asembler? > > > > Assemblers can be pretty simple, especially if the target is raw binary running > > at loaded at 0 rather than something needing linkers and libraries. Also helps > > if the target is RISC and doesn't have messy addressing modes. > > > > How much would a reasonably clean sample assembler help? There should be > > a good example from the academic world. Just type in the new opcode table. > > > "AS" from Alfred Arnold is a good wide-cores assembler, with a choice of > Pascal or C sources : > > http://john.ccac.rwth-aachen.de:8000/as/download.html > > And HLA (High Level Assembler) is currently x86 only, but the front > end, and approach is much closer to higher level languages (but minus > the bloat). V2 will allow different back ends, for opcode outputs. > Worth watching. > > http://webster.cs.ucr.edu/AsmTools/HLA/index.html > > This is able to support quite large code efforts, and remain > close to the iron.. > > A benefit of working from the 'best assembler' end, is the ease of > support multiple/tiny core instances - which is one of the > advantages of such soft cores. > > -jg Although an assembler is only a tiny fraction of the effort of a C compiler, once done it only opens the door just enough to bootstrap up slowly. For a processor to have much wider appeal needs the full effort either to port or write from scratch. I will probably set the hard type semantics of C aside for awhile and just add a very quick dirty codegen that handles C style assembler and simple 1 size expressions with none of the usual optimizations and just play dumb. Then baseline C/Verilog/Occam/inline asm can be written that might violate some proper rules. The compiler wouldn't be able to compile itself but I could get on with testbench and verification. Right now it can analyize itself but doesn't emit anything. It does have a nice #preprocessor built into the lexer that allows C++ like use of definitions with same name but varying no of params that is not described in lcc book. The usual way in the past was to define subsets of the target language and compile for that with the compiler also being restricted to that level. The 1st pass might be an assembler. The compiler could then operate at some level on the target and as the language subset is raised, the compiler gets to use the new features and tests them on the next round. I don't think people do that anymore unless the language is brand new and no compiler exists yet. Once it does exist, it's usually easier to cross port. This brings up a point, can a new compiler be $ distributed if the design is largely based off of previous open code. I will have to go check the license on lcc. johnjakson_usa_comArticle: 66627
Hi all,
I need to know if any of you have implemented a SHARC link port on
above- mentioned FPGA. If so what tools did U use?
Any info and direction will be gratefuly accepted.
--
end
Plain text reduces head-aches!!
" Cogito ergo, sum"
Joji John (nansung444@yahoo.com)
www.angelfire.com/ma3/joji
www.geocities.com/nansung444
Article: 66628
Hi,
I would also appreciate ideas.
THanx.
--
end
Plain text reduces head-aches!!
" Cogito ergo, sum"
Joji John (nansung444@yahoo.com)
www.angelfire.com/ma3/joji
www.geocities.com/nansung444
Joji John <nansung444@yahoo.com> wrote in message news:...
>
> Hi all,
> I need to know if any of you have implemented a SHARC link port on
> above- mentioned FPGA. If so what tools did U use?
> Any info and direction will be gratefuly accepted.
> --
> end
> Plain text reduces head-aches!!
> " Cogito ergo, sum"
> Joji John (nansung444@yahoo.com)
> www.angelfire.com/ma3/joji
> www.geocities.com/nansung444
>
>
Article: 66629Hi, I have a question concerning the VHDL description of a bidirectional bus. This bus comes from (goes to) an SRAM which I try to simulate with a corresponding VHDL model. Now I have an INOUT pin at my SRAM-Controller : Sram_data : inout(7 downto 0); Within my SRAM-Controller I have the local signals l_sram_data_out : std_logic_vector(7 downto 0); l_sram_data_in : std_logic_vector(7 downto 0); l_sram_data_out describes the data which I want to write into the SRAM. l_sram_data_out is a registered signal. l_sram_data_in describes the data I want to read from the SRAM. The signal which is responsible for writing to the SRAM or reading out of the SRAM is WE_bar. WE_bar='0' & CS_bar='0' & OE_bar='1' ---> Write to the SRAM WE_bar='1' & CS_bar='0' & OE_bar='0' ---> Read from the SRAM How can I connect l_sram_data_out and l_sram_data_in in a appropriate way to the bidirectional bus? Does l_sram_data_in has to be synchronized? (It is used within the controller in a synchronous environment) I would appreciate any helpful hint. Kind regards André V.Article: 66630
Hi, I try to program a JTAG chain with a MAX7064S and a MAX7032S via JTAG with a microcontroller. The problem is, that I couldn't find the JTAG opcodes for ISP. Is there any documentation about it? Thanks, PatrikArticle: 66631
Can recommend a decent supplier of the above parts in small qty for the UK? I've tried Emailing Insight Memec who have so far ignored me and Digikey who apparently don't stock them!! Also a supplier of NAND flash who also supply free simulation models would be nice!! but that's another story.Article: 66632
I am using Modelsim SE 5.8 to simulate cascaded DCMs. I have two DCMs cascaded, the first with CLKIN running at 10Mhz. I am using the CLK2X of the first as the CLKIN for the second DCM. The desired output is CLK2X of the second DCM (I am trying to generate a 40Mhz clock from a 10Mhz clock). When I simulate, I recieve the following warning: # ** Warning: Timing Violation Error : Input Clock Period Jitter on instance * exceeds 0.001 ns Locked CLKIN Period = 0.1 ns Current CLKIN Period = 0.3 ns # Time: 675 ns Iteration: 2 Instance: /dcmtest224/xlxi_1037 I cannot get the second DCM to lock as well. Any suggestions would be most appreciated. Best Regards, T. Justin CampbellArticle: 66633
Hi, When debugging a design one can assign inside the VHDL code debug pins. However, if after compiling and everything I decide to look for some other signal of choice (that are not pins), in the simulation, QUARTUS will give me a list of uninteligible names. Is there any way around this? Signal Tap seems to work only with a physical FPGA via JTAG. Thanks VadimArticle: 66634
"Joji John" <nansung444@yahoo.com> wrote in message news:c1fmjj$1gpfg7$1@ID-219060.news.uni-berlin.de... > > Hi all, > I need to know if any of you have implemented a SHARC link port on > above- mentioned FPGA. If so what tools did U use? > Any info and direction will be gratefuly accepted. Yes, I've done it in VHDL. It is really not that difficult. Read carefully the link port description in the DSP manual and create a state machine that follows it. /MikhailArticle: 66635
Ian <tau14@sussex.ac.uk> wrote: : Can recommend a decent supplier of the above parts in small qty for : the UK? : I've tried Emailing Insight Memec who have so far ignored me and : Digikey who apparently don't stock them!! : Also a supplier of NAND flash who also supply free simulation models : would be nice!! but that's another story. Nuhorizons list available parts. But probably they are prohibited by Xilinx to ship those parts to the UK. Ask them! Bye -- Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt --------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------Article: 66636
> I have a board that has a XCF02S and Spartan 3 400 (ES) connected in a > JTAG chain (the XCF02S is first in the chain). Attempting to > initialise the chain in Impact fails because the IDCODE coming out of > the FPGA is invalid (I have verified this on a scope - It is > reproducibly incorrect, and always the same value). Looking at the TDO > pin of the XCF02S / TDI pin of the FPGA, I can see that the IDCODE > coming out of the XCF02S is correct. > > If I take the XCF02S out of the chain, then the IDCODE from the FPGA > is correct and Impact is able to program the device. > > Should the value on the TDI pin of the FPGA effect the output of the > IDCODE? I just tried reversing the order of the JTAG chain (FPGA first, then PROM) and it now works. After numerious experiments, it seems that if there is any activity on the FPGA's TDI pin, then the IDCODE wont be output successfully. Cheers, JonBArticle: 66637
Ian wrote: > Can recommend a decent supplier of the above parts in small qty for > the UK? > > I've tried Emailing Insight Memec who have so far ignored me and > Digikey who apparently don't stock them!! Try phoning them; distributors don't take much notice of emails, I've found. > > Also a supplier of NAND flash who also supply free simulation models > would be nice!! but that's another story. -- Leon Heller, G1HSM Email: aqzf13@dsl.pipex.com My low-cost Philips LPC210x ARM development system: http://www.geocities.com/leon_heller/lpc2104.htmlArticle: 66638
Austin Lesea <austin@xilinx.com> wrote in message news:<c1dko2$l603@cliff.xsj.xilinx.com>... > ? > > Of course, there are more patents that Xilinx has filed since then. > > By the way, others have entered the FPGA business (an left it -- > unsuccessfully) and did not infringe on any patents, so it can be done. > > Why did they not succeed? Did it have to do with patents? > > Nope. > > Austin Nope indeed. Why waste more money on lawyers' fees when the others can self-destruct? But I'll bet you are your buddies at Altera would have used your patent portfolio at the whiff of any serious threat! > > Steve Casselman wrote: > > The earliest Xilinx patent is 4,870,302 Feb 19 1988. So it expires next year > > > > Steve Is this the famous Freeman patent? > > > > "Paul Franklin" <paulfr@dacafe.com> wrote in message > > news:518ec9d9.0402180243.2590fca0@posting.google.com... > > > >>I heard something about some major FPGA patents due to expire soon. I > >>think these are owned by Xilinx and/or Altera. > >> > >>I would be interested if anybody can clarify what exactly these > >>patents are, and if anyone has an opinion on if their expiry could > >>potentially enable market entry by new entrants to the FPGA arena or > >>new product families by the exisiting FPGA vendors. > >> > >>Regards, > >>Paul. > >> > > > > > >Article: 66639
The following code is my first Verilog program. It's running at 25MHz and that's what the counter is for. I'm trying to accomplish the same thing by shifting bits instead of hard coding the output in case statements. I tried LED<=LED>>1 to no avail. Any comments and suggestions are appreciated! Thanks! Kate module ledbounce(clk, LED); input clk; output [3:0] LED; reg [19:0] cnt1; reg [2:0] cnt2; reg a, b, c, d; wire cnt1max = (cnt1==1000000); always @(posedge clk) if(cnt1max) cnt1 <= 0; else cnt1 <= cnt1 +1; always @(posedge clk) if(cnt1max) begin if(cnt2==5) cnt2<=0; else cnt2<=cnt2+1; end always @(posedge clk) begin case(cnt2) 0 : begin a = 1; b = 0; c = 0; d = 0; end 1 : begin a = 0; b = 1; c = 0; d = 0; end 2 : begin a = 0; b = 0; c = 1; d = 0; end 3 : begin a = 0; b = 0; c = 0; d = 1; end 4 : begin a = 0; b = 0; c = 1; d = 0; end 5 : begin a = 0; b = 1; c = 0; d = 0; end endcase end assign LED[0] = a; assign LED[1] = b; assign LED[2] = c; assign LED[3] = d; endmoduleArticle: 66640
jon@beniston.com (Jon Beniston) wrote in message news:<e87b9ce8.0402240132.7a92aa17@posting.google.com>... > > Cache architecture is > > currently 1 way set associative, but more Blockrams would allow more > > ways. > > Do you not think that the number of ways has to be as least as great > as the number of threads? I would expect a significant amount of > conflict misses (particularly in the I-Cache) if this is not the case. > Hit-under-miss is a must. > Otherwise all those impressive Mega-Hurtz will just be thown away > stalling for cache refills. > > Cheers, > Jo Hi Jon Not neccesarily. On a conventional HT cpu, the threads would all be independant, and likely fight over the cache set size and 2 way would probably be a min. Since these threads are supposed to be cooperating as Occam proceses would, then their opcodes would be local but that assumes sibling processes run close to each other in time space. No guarantee of that. In the HW event driven case, its much easier to speculate about what will likely happen as the scheduling model is so much simpler. Even if there are lots of conflicts what will happen is the threads will just keep delaying. In the HW time wheel, there are actually 16 threads waiting to go (or null Ps if less available). These 16 represent the front of the proper P queue stored in linklist out in memory space (only some of which might be in cache at any time). The HW only allows the front 4 of those to queue up in the Iop queue. The fetcher steals or forces available cache reads slots to keep this full rotating between the 4 queues which live inside distributed 16b DP rams by 64 wide. Hence each running thread can buffer up to 16 small ops or 4 extended 64b ops or some mix. On a side note, if the cpu were 64b wide, the HT would have to be 8way, but then the Iqueue HW would be twice as wide too so that still allows each P to buffer up same no of ops. I would have to tweak the HDL code to group the rams for hight v width keeping it 64b wide output always. Wider data ops doesn't really change the opcode fetch rate since that now looks half as much as before. The fractional costs of executing ops now changes from 9/8 to 17/16 cycles for ALU a<-b OP c; so a slight speed up. Putting large literals or actual addresses in code space would wipe that out. The fetcher also write the Pid with the opcodes and it does a superficial check to see if any 16b ops are bra codes or not. If it pushes a bra, it will then keep pushing just a few more words until its past and then rotate that Pid out and take the next one from the other 12 waiting. The other side of the Iop queue just reads the 1-4 wide opcodes with the Pid and decode/execute the ops. It tracks the opcode size and uses any bra codes as just another contol field. By the time the bra decision is available, the Iop box will have executed >>4 ops, but then it will have been P switched already. The bra decision when it does arrive will post back the modified ip into the Pid selected ip field. Pid rides along the datapath pipeline too. Bra pts may be used to do the outer timesharing but I may leave that to a SW kernal. Cache misses will probably be treated same way, if the miss is going to be long, switch to the next P in the side queue. You can imagine a little railway track figure of 8 made up of selective pipelines & muxes holding minimal P state. Something like Johnson logic or hot coded state engine in charge. One huge difference between this HT processor and the ones you hear about x86, Alpha etc, I expect to use RLDRAM as 2nd level cache which RAS cycles in 20ns which is about 1.5 effective cpu cycles 13.3ns. It is 8way banked and can support 2.5ns datarates and control. I will probably be limited to the 311MHz rate and DDR is limited to 622MHz in the specs (conveniant 2x), this is right on the edge of what FPGAs can do and below the RLDRAM2 800MHz std. Remember x86 in particular has to be designed to work with very slow RAS elcheapo DDR Rams which can be several 100x slower than cpu cycles. Intel can't do a special tweak for RLDRAM since the difference is still very large, maybe 50 or more. In this cpu I could almost throw cache out and go direct to RLDRAM as main memory which is why I am not too concerned about tiny cache. I will be building an RLDRAM model soon by faking a bunch of 8 Blockrams together with delays and muxes demuxes. This will let me test out 1-8 cpu models running with faked RLDRAM all inside a sp-400 part. Further a 64b 8way HT cpu would actually cycle slower than RLDRAM ie 26ns. The real purpose of the cache which is a unified data-instruction-workspace is to satisfy the enormous bandwith req of the workspace operations. Reg cpus have 1 or more reg files separate from d/i cache but they have the burden of very high swap contexts. R3 keeps many workspaces in uni cache and provide 3ports to datapath 2 reads and 2joined writes using a pair of DP rams. The instr and data fetch requirements could be met by fast RLDRAM without cache, some buffering would still be needed. The T9000 style workspace caching is what makes this all work and that the cpus run close to RLDRAM speed. If R3 ever went ASIC and n x faster, ofcourse the cache would go full cuctom and bigger by far. Hope that helps johnjakson_usa_comArticle: 66641
Timothy, 1) You must hold the cascaded DM in reset until the first DCM has locked 2) The tool is correct, cascading DCM CLK2X is not recommended, as the jitter out of the first exceeds the specs of the input of the second. They will work, but the resulting jitter out of the second one is not pretty (probably close to 400 to 600 ps P-P, which may be alright for your application). Oh, and one last item, 10 MHz is too low a frequency to go into a DCM with (Fin min is > 24 MHz). AustinArticle: 66642
Kevin Brace <kev0inb1rac2e@m3ail.c4om> wrote: > Hi, > > Mine isn't going to be free, but . . . I am considering releasing a PCI > IP core I have been working on for quite some time, and I am trying to > gauge the demand out there for a commercial-grade PCI IP core for > personal users. > However, the PCI IP core itself probably won't be available for another > three months at the earliest (I still need to fix some minor problems, > and setup the infrastructure before the release.). > The price I am thinking of charging for my PCI IP core is only $100 > (USD) as long as the licensee meets the following conditions. > > * The licensee resides within the United States (Don't have to be a US > citizen.). > * The licensee Will agree that the PCI IP core will be used only for > non-commercial, non-profit, non-academic research, and personal > purposes. > * The licensee is will agree, sign, and mail back to a license agreement > form I will provide. > * The licensee will pay for the PCI IP core license through an online > payment source like PayPal. > Rather heavy-handed set of restrictions, don't you think? -- Sander +++ Out of cheese error +++Article: 66643
"Kate Smith" <lsdjf@dlfjc.om> wrote in message
news:bNidnZqo8vXL4KbdRVn-uQ@comcast.com...
> The following code is my first Verilog program. It's running at 25MHz and
> that's what the counter is for. I'm trying to accomplish the same thing
by
> shifting bits instead of hard coding the output in case statements. I
tried
> LED<=LED>>1 to no avail. Any comments and suggestions are appreciated!
> module ledbounce(clk, LED);
> input clk;
> output [3:0] LED;
>
> reg [19:0] cnt1;
> reg [2:0] cnt2;
> reg a, b, c, d;
> wire cnt1max = (cnt1==1000000);
[snip code]
First, it's worth noting that you are more likely to get an
answer on comp.lang.verilog than here - although many of us
read both groups.
Second, you can't manipulate output LED as you tried, because
it's a wire, not a reg - you declared it correctly as an
output, but outputs are wires by default. You need to do the
shift operations on the register you've represented as
a,b,c,d.
Third, although I can see the sense in your counter arrangement,
the second counter is not really necessary - you could use the
"bouncing bit" 4-bit register as its own counter.
Fourth, you REALLY need to think about reset strategy -
in many FPGA and CPLD devices, flip-flops start life with
zero in them, but it's a bad idea to rely on this.
So, here's my suggestion:
(1) Throw away your cnt2 logic and registers a,b,c,d.
(2) Make the bouncing-bit counter like this:
reg LeftNotRight;
reg [3:0] LED; // This in addition to the output declaration
...
always @(posedge clk or posedge reset)
if (reset) begin
LED <= 1;
LeftNotRight <= 1;
end else if (cnt1max) begin
if (LeftNotRight) begin // Going left
if (LED[3])
LeftNotRight <= 0;
else
LED <= LED << 1;
end else begin // Going right
if (LED[0])
LeftNotRight <= 1;
else
LED <= LED >> 1;
end
end
For lots of extra credit, see if you can work out
a) what happens if the LED register gets more than
one of its bits set, for any reason;
b) what happens if the LED register becomes zero
for any reason, and what you might do to fix it
:-)
--
Jonathan Bromley, Consultant
DOULOS - Developing Design Know-how
VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services
Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK
Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com
Fax: +44 (0)1425 471573 Web: http://www.doulos.com
The contents of this message may contain personal views which
are not the views of Doulos Ltd., unless specifically stated.
Article: 66644
qlyus,
I don't know, but I suspect that this is the case:-
1) The differential receivers works over a very large common mode
range. The common mode voltage probably affects the switching speed
though.
2) The receivers work with very small differential voltages, with the
gotcha being that the smaller the differential voltage the slower the
switching.
3) Xilinx only test the parts to the specifications you quote, because
they can't, or it's too expensive to, check all inputs over all common
mode voltages and differential voltages meet all timing for every part
off the production line.
So, it's physically the *same* receiver, it's just only tested at
the two LVPECL (and the LVDS I guess) points you quote.
Good luck, Symsx.
Article: 66645> > Second, you can't manipulate output LED as you tried, because > it's a wire, not a reg - you declared it correctly as an > output, but outputs are wires by default. You need to do the > shift operations on the register you've represented as > a,b,c,d. > I don't see why what she's done wouldn't work. Her registers a,b,c, and d change at the clock edge and the LED wires are connected to the outputs of the registers. The only problem I might see is that it runs a bit fast. The "state machine" changes states at 25Hz and it might be hard to see the LEDs blink that quickly. -KevinArticle: 66646
"Kevin Neilson" <kevin_neilson@removethiscomcast.net> wrote in message news:ZSL_b.5237$AL.131989@attbi_s03... > I don't see why what she's done wouldn't work. Her registers a,b,c, and d > change at the clock edge and the LED wires are connected to the outputs of > the registers. The code as presented was fine, yes. I was talking about the attempt to set LED <= LED >> 1, as mentioned at the start of the original post. Sorry I didn't make that clear. -- Jonathan Bromley, Consultant DOULOS - Developing Design Know-how VHDL * Verilog * SystemC * Perl * Tcl/Tk * Verification * Project Services Doulos Ltd. Church Hatch, 22 Market Place, Ringwood, Hampshire, BH24 1AW, UK Tel: +44 (0)1425 471223 mail: jonathan.bromley@doulos.com Fax: +44 (0)1425 471573 Web: http://www.doulos.com The contents of this message may contain personal views which are not the views of Doulos Ltd., unless specifically stated.Article: 66647
> > > > Steve Casselman wrote: > > > The earliest Xilinx patent is 4,870,302 Feb 19 1988. So it expires next year > > > > > > Steve > > Is this the famous Freeman patent? > > > > Likely, although one company A. might refer to it as 'infamous' :) :) US4870302: "Configurable electrical circuit having configurable logic elements and configurable interconnects" Inventor: Ross H. Freeman, San Jose, Calif. Assignee: Xilinx, Inc., San Jose, Calif.Article: 66648
Chris Jones wrote: > Consider the grid shown below. > > There are 4 electrical "switch pairs" which need to be connected to > make the overall connection work. > > --------------------------------------------------------- > | | | | | | | | | | | | | | | > --------------------------------------------------------- > | | | | | | | | | | | | | | c`| > --------------------------------------------------------- > | | | | | | | | | | | | | | | > --------------------------------------------------------- > | | | | b | | | | | | | | | | | > --------------------------------------------------------- > | | | | | | | | | | | | | d'| | > --------------------------------------------------------- > | | | | | | | | | | | | | | | > --------------------------------------------------------- > | | | | | | | | | | | | | | | > --------------------------------------------------------- > | | | | | | a | | | | | a`| | | | > --------------------------------------------------------- > | | | | | | | | | | | | | | | > --------------------------------------------------------- > | | | | | | | | | | | | | | | > --------------------------------------------------------- > | | | | | | | | | | | b`| | | | > --------------------------------------------------------- > | | | | | | | d | | | | | | | | > --------------------------------------------------------- > | | | | | | | | | | | | | | | > --------------------------------------------------------- > | | c | | | | | | | | | | | | | > --------------------------------------------------------- > > The paths are > > a --- a' (path A) > b --- b' (path B) > c --- c' (path C) > d --- d' (path D) > > There would be two possible routes to connect these paths. The > connection can follow either 1) horizontal then vertical direction, > or 2) vertical then horizontal direction. There ie no other way that > the path between the electrical switches could be made. Thus every > possible path here would make a bounded rectangle encompassing the > pair of switches. > > The following rule is to be followed for making up these paths: > > If a switch p belonging to one path lies in the bounded rectangle > formed by the switches belonging to another path, then path p must be > connected first. > > SO - What would be the order of connectivity of this set of paths? > > AND - Develop a generalized procedure to implement this strategy! > > Thanks, > Chris First, determine how you would do this in your head. Then try to do it on paper. Then pretend to be a dumb computer and do it on paper again. Then you should have a good idea how the program will work. Seems, unless I've misread it, that this network is soluble in alphabetical order: a-a': trivial. b-b': across/down fails because of a-a'; down/across works. c-c': could go either way d-d': up/right crosses a-a' but right/up is ok. So in my head I'm marking cells that have been visited by existing connections, then for subsequent connections considering if those cells are already occupied. It's not hard to see that in other arrangements, abcd might not be possible but some other order is, so you'll need to run through the possible variations from abcd to dcba, listing the orders that work. Dave.Article: 66649
Does anyone have any experience simulating RocketIO in Modelsim SE via use of SmartModels. I am trying to stimulate the TXP and TXN pins of the MGT via use of a .do file. Is there are proper way to do this, or is the following acceptable: restart -f force RocketIO_10mhz 0 0ns, 1 50ns -repeat 100ns run 2us run 50ns force RXNIn1_Data 1 force RXPIn1_Data 0 run 100ns force RXNIn1_Data 1 force RXPIn1_Data 0 run 100ns force RXNIn1_Data 1 force RXPIn1_Data 0 run 100ns force RXNIn1_Data 0 force RXPIn1_Data 1 run 100ns force RXNIn1_Data 0 force RXPIn1_Data 1 run 100ns force RXNIn1_Data 0 force RXPIn1_Data 1 run 100ns force RXNIn1_Data 1 force RXPIn1_Data 0 run 100ns force RXNIn1_Data 1 force RXPIn1_Data 0 run 100ns force RXNIn1_Data 0 force RXPIn1_Data 1 run 100ns force RXNIn1_Data 1 force RXPIn1_Data 0 run 100ns p.s. The input clock to the MGT is running at 40Mhz Best Regards, T. Justin Campbell
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