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 don't know if 8.x still does it, but in previous versions when trying to load projects with spaces in the path name, it would actually give you an error mesage telling you that it did not support spaces. IIRC, Windows has had long path name support for about 11 years.Article: 99501
Does each ppc have an elf file? If so that would probably be a problem, I don't think you can generate an ace file with more than one elf (anyone who knows differently will hopefully correct me). I think the previous advice was assuming that at least one of your ppcs has it's entire program living on chip. If that were the case then there shouldn't be a problem, you'd only have one elf that needed to be part of the ace. Does the address space of BOTH the ppcs contain stuff off the FPGA?Article: 99502
The source comes with scripts for Design Compiler. I guess they want you to use that tool; which is for targetting ASICs.Article: 99503
Oh, and I don't have a gate count but the design is quite large:
[gliss@precision design]$ find ~/opensparc/design -name "*.v" -exec cat
{} \; | wc -l
323957
There are over 320,000 lines of Verilog and the support scripts are
built for a DC ASIC synthesis environment... good luck getting that to
fit in an FPGA.
Article: 99504
Chris,
Brings up a question for the group: how many lines of verilog can you
fit in any given FPGA?
Anyone out there in the ASIC emulation world care to comment?
Being a 'hardware' type, I am just ignorant...
Austin
chrisbw@gmail.com wrote:
> Oh, and I don't have a gate count but the design is quite large:
>
> [gliss@precision design]$ find ~/opensparc/design -name "*.v" -exec cat
> {} \; | wc -l
> 323957
>
> There are over 320,000 lines of Verilog and the support scripts are
> built for a DC ASIC synthesis environment... good luck getting that to
> fit in an FPGA.
>
Article: 99505
Austin Lesea wrote:
> Chris,
>
> Brings up a question for the group: how many lines of verilog can you
> fit in any given FPGA?
It's a meaningless question without considering the exact nature of
the Verilog code.
For example, a complex control FSM described in several pages of
code may require less than 100 gates. On the other hand, a simple
(but wide) flip-flop intensive data path, described in a few lines,
may require 10000 gates or more.
As for the SPARC code, it seems like an extreme example. I wouldn't
call this RTL code. It's more like a manually generated technology-
independent netlist. For example, they don't even use flip-flop
inference. And they do have excessive hierarchy.
I suspect that it should be possible to gain at least an order
of magnitude in terms of lines of code by using a proper RTL
style. And the synthesis results might be better. (Excessive
hierarchy tends to yield suboptimal synthesis results).
Regards,
Jan
--
Jan Decaluwe - Resources bvba - http://www.jandecaluwe.com
Losbergenlaan 16, B-3010 Leuven, Belgium
From Python to silicon:
http://myhdl.jandecaluwe.com
Article: 99506Jan, OK, that makes sense. I had thought the "law of large numbers" would take over with enough code, but if this code is handcrafted for ASIC cell applications (with extremely primitive cells), then it would synthesize very poorly for anything but that application. Austin Jan Decaluwe wrote: > Austin Lesea wrote: > >> Chris, >> >> Brings up a question for the group: how many lines of verilog can you >> fit in any given FPGA? > > > It's a meaningless question without considering the exact nature of > the Verilog code. > > For example, a complex control FSM described in several pages of > code may require less than 100 gates. On the other hand, a simple > (but wide) flip-flop intensive data path, described in a few lines, > may require 10000 gates or more. > > As for the SPARC code, it seems like an extreme example. I wouldn't > call this RTL code. It's more like a manually generated technology- > independent netlist. For example, they don't even use flip-flop > inference. And they do have excessive hierarchy. > > I suspect that it should be possible to gain at least an order > of magnitude in terms of lines of code by using a proper RTL > style. And the synthesis results might be better. (Excessive > hierarchy tends to yield suboptimal synthesis results). > > Regards, > > Jan >Article: 99507
Hello, does somebody know whether it is possible to get the Nios II-VHDL source code. There is an ASIC license avialable. What does that license cost? Thanks. UdoArticle: 99508
Hello, does somebody know more details about the Nios II-branch prediction? I know only that two types are supported - static and dynamic. Any more details? Thanks. UdoArticle: 99509
I am not sure how it is for Nios II, but in general. For static branch prediction, the CPU makes a fixed prediction when it encounters a conditional branch in the instruction stream. For example if the CPU encounters a jump on zero flag set, a static branch predictor will assume that the CPU will take the branch. It does not use the history of the instruction to determine if it will branch or not. This I believe has pretty good results. A dynamic branch predictor works on the history of the instruction stream to determine if a jump will take place. For example if the CPU encounters the same aforementioned instruction, it will look into internals to determine the history of the instruction and make a prediction based on that. The function to keep track of this varies widely. A good example to look at would be the original Intel Pentium's BTB (Branch Target Buffer). Or looking at the way the P2 or P3 do it. The methods these chips use are ingenious and have very good prediction rates, but by the looks of it, they do require some complicated hardware. Obviously the dynamic predictor will have better prediction records than the static, but the static is FAR easier to implement. Here is a link: http://www.x86.org/articles/branch/branchprediction.htm I was reading this article sometime ago and was very impressed with the method Intel used. Perhaps somebody could post a link to a better method than this, than I will faint :). -IsaacArticle: 99510
Hi, I apologize if I sound like I don't know what I'm talking about. I am primarily a C programmer, but I am involved in a hardware design project at the moment, and would like some advice. The 'proof of concept' phase of the development is being done in VHDL, with a processor core implementing some of the features. As the features will be incomplete when the project is handed over to me (due to time constraints), I will need to make modifications to the hardware design. My preference is to develop in C for now as the functionality required is easily implemented in C, while learning VHDL is going to take quite some time. I've been investigating C-based languages, in particular SystemC, SpecC, and FpgaC. SystemC is based on C++ classes, and FpgaC is still rather incomplete. SpecC looks like a good option, but I can't find any details about how the output can be used to programme a FPGA. Knowing not all vendor software is compatible, is SpecC suitable for this purpose? My second question surrounded the mixing of languages. Is it possible for me to use SpecC or another language, while still making use of the VHDL code that has already been written and tested? Thanks, The Other GuyArticle: 99511
Hi Udo,
Your chances of getting a reply from an expert are much better if you
post Nios questions on www.niosforum.com .
- Subroto Datta
Altera Corp.
"Udo" <WeikEngOff@aol.com> wrote in message
news:1143324190.583196.306100@g10g2000cwb.googlegroups.com...
> Hello,
>
> does somebody know more details about the
> Nios II-branch prediction? I know only that
> two types are supported - static and dynamic.
> Any more details?
>
> Thanks.
> Udo
>
Article: 99512
The Other Guy wrote:
> My preference is to develop in C for now as the functionality required
> is easily implemented in C, while learning VHDL is going to take quite
> some time.
C is fine for programs that run on the processor core,
if that is working. For hardware changes, your best
bet is to modify and simulate the VHDL code you already have,
or find someone who can.
> I've been investigating C-based languages, in particular SystemC, SpecC,
> and FpgaC. SystemC is based on C++ classes, and FpgaC is still rather
> incomplete. SpecC looks like a good option, but I can't find any details
> about how the output can be used to programme a FPGA. Knowing not all
> vendor software is compatible, is SpecC suitable for this purpose?
I would hesitate to rewrite a working processor core
in any case. Changing to a fledgling description
language would further reduce your odds of success.
> My second question surrounded the mixing of languages. Is it possible
> for me to use SpecC or another language, while still making use of the
> VHDL code that has already been written and tested?
Anything is possible, but I would either stick
with VHDL or start over. You will almost certainly
be making interacting changes in both the new and old
hardware descriptions -- and you will have to run simulations
on the whole thing.
-- Mike Treseler
Article: 99513Hello Burns, Synplify generates an SDC file (xxx_sdc.sdc) that can be imported into Designer. So there is no need to create two different constraint files. Initially, I would use the Synplify constraint editor to create the false path definitions. This way, you have valid constraints to start with. Regards, DanielArticle: 99514
What a waste of my time! (A cautionary rant)
As part of a re-engineering of a 15 year old product, I need a ROM
with pre-settable output in a Spartan 3. It is company policy to try to
write for vendor indepence, so the ROM has to be coded in VHDL, and I
cannot use Coregen (even though I know this product will never be
targeted to any other part, at least for another 10 years). The 8.1i
release of ISE has support for "synchronously controlled initialization
of the RAM data outputs" (pg 218 of XST User Guide) and for RAM
initialization (pg 226). Thinking I can be clever about it, I code up a
RAM with initial values and also with output initialization:
type ram_type is array (0 to 255)
of std_logic_vector(7 downto 0);
signal RAM : ram_type := (
X"12", X"34", yadda, yadda, yadda,
constant Init_Value : std_logic_vector( 7 downto 0 )
:= x"FE";
...
process( Clk ) begin
if RISING_EDGE( Clk ) then
if CE = '1' then
if WE = '1' then
RAM (TO_INTEGER(Addr)) <= DI;
end if;
if rst = '1' then -- optional reset
D_Out <= Init_Value;
else
D_Out <= RAM(TO_INTEGER(addr)) ;
end if; end if; end if;
end process;
and then just tie off we:
WE <= '0';
What does XST do with this? It sees WE tied off, realizes this is a
ROM, not a RAM, and spits out the message:
INFO:Xst:1649 - Currently unable to implement this ROM as a read-only
block RAM. Please look for coming sofware updates.
Arrrrgh! This, in spite of the fact that there is no trouble at all if
WE is not tied off. I know it is not the case that someone is just
being perverse, but right now it sure feels like it. Tools, ya gotta
love 'em.
Article: 99515Hi Ajeetha, If I pass clk to test_lib, shall I use `include "test_lib.v"? Best regards, DavyArticle: 99516
Davy,
That wouldn't change from the way you currently compile it. Say:
vcs test_lib.v test.v
Only the instantiation changes:
>>test_lib test_lib();
test_lib test_lib(.clk(clk));
HTH
Ajeetha CVC
www.noveldv.com
Article: 99517
Pablo Bleyer Kocik wrote:
>
> Thanks for the pointers. I will try that.
>
I couldn't turn up that other post that I recalled, but I dug
up a code snippet of the conditional signed skips of my own
homebrew processor. ( no mid-chain split, but overflow logic
coded with pad bits )
Basically, the copy of the MSB input bits at bit position
MSB+1 lets you indirectly look for a difference in the carries
into and out of the MSB position in the inferred RTL adder.
gen_sgbt: if CFG_SKIP_GROUP_B = TRUE generate
skip_b: block
signal wide_diff : std_logic_vector( ALU_MSB+2 downto 0);
signal pad_ar : std_logic_vector( ALU_MSB+2 downto 0);
signal pad_br : std_logic_vector( ALU_MSB+2 downto 0);
begin
pad_ar <= ( '0' & ar(ALU_MSB) & ar );
pad_br <= ( '0' & br(ALU_MSB) & br );
wide_diff <= pad_ar - pad_br;
-- sign, carry, overflow, zero bits
cb_n <= wide_diff(ALU_MSB);
cb_c <= wide_diff(ALU_MSB+2);
cb_v <= wide_diff(ALU_MSB+1) XOR wide_diff(ALU_MSB);
cb_z <= '1' when ( wide_diff(ALU_MSB downto 0) = ALU_ZERO ) else
'0';
end block skip_b;
--
-- mux for skip_b condition decoding
--
skip_decode_b: process(skip_sense, skip_type, cb_z, cb_n, cb_c,
cb_v)
variable skip_mux_b : std_logic;
begin
-- mux condition sources
case skip_type is
when CND_LO => skip_mux_b := cb_c;
when CND_LS => skip_mux_b := cb_z OR cb_c;
when CND_LT => skip_mux_b := cb_n XOR cb_v;
when CND_LE => skip_mux_b := (cb_n XOR cb_v) OR cb_z;
when others => skip_mux_b := '1';
end case;
if skip_sense = '0' then
skip_cond_b <= skip_mux_b;
else
skip_cond_b <= NOT skip_mux_b;
end if;
end process skip_decode_b;
end generate gen_sgbt;
Which implements:
SCCB : skip conditions, group B
000 0 skip.lo lower unsigned, RA < RB
100 0 skip.hs higher or same unsigned, RA >= RB
001 0 skip.ls lower or same unsigned, RA <= RB
101 0 skip.hi higher unsigned, RA > RB
010 0 skip.lt less than signed, RA < RB
110 0 skip.ge greater than or equal signed, RA >= RB
011 0 skip.le less than or equal signed, RA <= RB
111 0 skip.gt greater than signed, RA > RB
There's also a great explanation of generating conditionals and
overflows in sections 2-11 through 2-13 of "Hacker's Delight", Warren,
Addison Wesley, 2003
Brian
Article: 99518>The older code was getting synthesized in around 20 mins, but the new > code takes hours together to get synthesized, and so does the PAR. > How can we reduce the synthesis time? Why is that the code which > took lesser time to get synthesized is now taking longer? One thing I've noticed with XST and state machines is that past a certain complexity, XST run time goes up exponentially when adding more states (quickly changing from minutes to hours) Although since you describe only four states, that may not be your exact problem. You might try turning off/changing the state machine inference and encoding settings. What version XST? Any weird warnings? State machine tested in simulation for init/recovery on unexpected inputs? See also Answer Records 20366, 22654, 22637, 21682 BrianArticle: 99519
I found this in design/sys/iop/sparc/ifu/rtl/sparc_ifu_rndrob.v
....
assign next_pv[0] = pv[0] | reset;
dff #4 park_reg(.din (next_pv),
.clk (clk),
.q (park_vec),
.se (se), .si(), .so());
....
I don't see how the #4 is legal is Verilog 2001.
Can someone explain to me under what it means,
and under what circumstances this is legal?
Is this construct part of Verilog 2001, or is it vendor specific?
-- IDB
Article: 99520On 2006-03-25, leaf <adventleaf@gmail.com> wrote: > Yes you're minipci design worked on my pc, i did somehow used it as a > reference, and somehow i have managed to port it into my new design, > unfortunately the former did'nt worked on all PC on our lab. I'm not sure which design you had problems with -- mine or your modified version. One thing to be aware of is that modern PCI bridge chipsets have configurable clocks and the BIOS will disable a slot entirely if it's not happy with the initial configuration requests to the card. If your code works at the first boot, you can often re-flash the card while booted (provided the CPLD or FPGA tristates during the programming and assuming your code comes up in a sane state without seeing a PCI RST). However, if your card was not detected at boot, you probably can't reload it and see it work unless you also restart the PC. Also, my core did not generate PAR at all because the fan-in for the necessary XOR wasn't possible in the small CPLD I was using. > note with regards to screenshot: > Will the bus master work with this kind of target (i.e. having Medium > Devsel timing)? The devsel timing has to meet the spec you put in your config space. If you say "fast" and don't respond on the clock after the address cycle, then the initiator could assume that no one will ever reply. I'm not sure if (or even how) that would apply to config cycles. Also, in your simulation you have a config space read at address '1' which should really be a read at 0 with byte enables. And you return all '1's which would not be valid and could cause the problem I described above with your BIOS. -- Ben Jackson <ben@ben.com> http://www.ben.com/Article: 99521
Hi Ajeetha, All OK, thank you! Best regards, DavyArticle: 99522
Plain ol' verilog udp?Article: 99523
Brian, with the following exploded setup I could finally instruct ISE
to merge two 8-bit adders to create a 16-bit one and multiplex out the
carry to get the half-carry. I don't know why my previous setups
failed... It saves 4 slices in a SP3 instead of having two separate
adders (the output mux is not considered) and the report indeed shows
that the fanout of the half MUXCY is 2.
Regards.
---8<---
`define WIDTH 16
/* Two half adders to create a full one */
module addsub1(
op, oc, y, a, b, c_in,
c_out, h_out
);
input op, oc; // 0: add, 1: sub
output [`WIDTH-1:0] y;
input [`WIDTH-1:0] a, b;
input c_in;
output c_out;
output h_out;
wire [`WIDTH/2-1:0] yh, yl;
wire [`WIDTH/2-1:0]
ah = a[`WIDTH-1:`WIDTH/2], al = a[`WIDTH/2-1:0];
wire [`WIDTH/2-1:0] bh, bl;
wire c =
(!oc) ? 0 :
(op) ? ~c_in : c_in;
wire d, e;
assign bh = (op) ? ~b[`WIDTH-1:`WIDTH/2] : b[`WIDTH-1:`WIDTH/2];
assign bl = (op) ? ~b[`WIDTH/2-1:0] : b[`WIDTH/2-1:0];
assign {d, yl} = al + bl + c;
assign {e, yh} = ah + bh + d;
assign h_out = (op) ? ~d : d;
assign c_out = (op) ? ~e : e;
assign y = {yh, yl};
endmodule
/*
=========================================================================
* HDL Synthesis
*
=========================================================================
Synthesizing Unit <addsub1>.
Related source file is "C:/src/pacoblaze/pacoblaze/addsub.v".
Found 8-bit adder carry in/out for signal <$n0001>.
Found 8-bit adder carry in/out for signal <$n0002>.
Found 1-bit 4-to-1 multiplexer for signal <c>.
Summary:
inferred 2 Adder/Subtractor(s).
inferred 1 Multiplexer(s).
Unit <addsub1> synthesized.
=========================================================================
HDL Synthesis Report
Macro Statistics
# Adders/Subtractors : 2
8-bit adder carry in/out : 2
# Multiplexers : 1
1-bit 4-to-1 multiplexer : 1
=========================================================================
=========================================================================
* Advanced HDL Synthesis
*
=========================================================================
=========================================================================
Advanced HDL Synthesis Report
Macro Statistics
# Adders/Subtractors : 2
8-bit adder carry in/out : 2
# Multiplexers : 1
1-bit 4-to-1 multiplexer : 1
=========================================================================
=========================================================================
* Low Level Synthesis
*
=========================================================================
Loading device for application Rf_Device from file '3s200.nph' in
environment C:\Xilinx.
Optimizing unit <addsub1> ...
Mapping all equations...
Building and optimizing final netlist ...
Found area constraint ratio of 100 (+ 5) on block addsub1, actual ratio
is 0.
=========================================================================
* Final Report
*
=========================================================================
Final Results
RTL Top Level Output File Name : addsub1.ngr
Top Level Output File Name : addsub1
Output Format : NGC
Optimization Goal : Speed
Keep Hierarchy : NO
Design Statistics
# IOs : 53
Cell Usage :
# BELS : 67
# LUT2 : 34
# LUT3 : 1
# MUXCY : 16
# XORCY : 16
# IO Buffers : 53
# IBUF : 35
# OBUF : 18
=========================================================================
Device utilization summary:
---------------------------
Selected Device : 3s200pq208-5
Number of Slices: 19 out of 1920 0%
Number of 4 input LUTs: 35 out of 3840 0%
Number of bonded IOBs: 53 out of 141 37%
=========================================================================
TIMING REPORT
NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE.
FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT
GENERATED AFTER PLACE-and-ROUTE.
Clock Information:
------------------
No clock signals found in this design
Timing Summary:
---------------
Speed Grade: -5
Minimum period: No path found
Minimum input arrival time before clock: No path found
Maximum output required time after clock: No path found
Maximum combinational path delay: 12.573ns
Timing Detail:
--------------
All values displayed in nanoseconds (ns)
=========================================================================
Timing constraint: Default path analysis
Total number of paths / destination ports: 824 / 18
-------------------------------------------------------------------------
Delay: 12.573ns (Levels of Logic = 21)
Source: op (PAD)
Destination: c_out (PAD)
Data Path: op to c_out
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
IBUF:I->O 19 0.715 1.403 op_IBUF (op_IBUF)
LUT2:I1->O 1 0.479 0.976 bl<0>1 (bl<0>)
LUT2:I0->O 1 0.479 0.000 addsub1_yl<0>lut (N4)
MUXCY:S->O 1 0.435 0.000 addsub1_yl<0>cy
(addsub1_yl<0>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub1_yl<1>cy
(addsub1_yl<1>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub1_yl<2>cy
(addsub1_yl<2>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub1_yl<3>cy
(addsub1_yl<3>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub1_yl<4>cy
(addsub1_yl<4>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub1_yl<5>cy
(addsub1_yl<5>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub1_yl<6>cy
(addsub1_yl<6>_cyo)
MUXCY:CI->O 2 0.056 0.000 addsub1_yl<7>cy (d)
MUXCY:CI->O 1 0.056 0.000 addsub1_yh<0>cy
(addsub1_yh<0>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub1_yh<1>cy
(addsub1_yh<1>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub1_yh<2>cy
(addsub1_yh<2>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub1_yh<3>cy
(addsub1_yh<3>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub1_yh<4>cy
(addsub1_yh<4>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub1_yh<5>cy
(addsub1_yh<5>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub1_yh<6>cy
(addsub1_yh<6>_cyo)
MUXCY:CI->O 1 0.265 0.976 addsub1_yh<7>cy (e)
LUT2:I0->O 1 0.479 0.681 c_out1 (c_out_OBUF)
OBUF:I->O 4.909 c_out_OBUF (c_out)
----------------------------------------
Total 12.573ns (8.538ns logic, 4.035ns route)
(67.9% logic, 32.1% route)
*/
/* Two separate adders */
module addsub2(
op, oc, y, yl, a, b, c_in,
c_out, h_out
);
input op, oc; // 0: add, 1: sub
output [`WIDTH-1:0] y;
input [`WIDTH-1:0] a, b;
input c_in;
output c_out;
output h_out;
output [`WIDTH/2-1:0] yl;
wire [`WIDTH/2-1:0]
al = a[`WIDTH/2-1:0];
wire [`WIDTH-1:0] bs;
wire [`WIDTH/2-1:0] bl;
wire c =
(!oc) ? 0 :
(op) ? ~c_in : c_in;
wire d, e;
assign bl = (op) ? ~b[`WIDTH/2-1:0] : b[`WIDTH/2-1:0];
assign bs = (op) ? ~b : b;
assign {d, yl} = al + bl + c;
assign {e, y} = a + bs + c;
assign h_out = (op) ? ~d : d;
assign c_out = (op) ? ~e : e;
endmodule
/*
=========================================================================
* HDL Synthesis
*
=========================================================================
Synthesizing Unit <addsub2>.
Related source file is "C:/src/pacoblaze/pacoblaze/addsub.v".
Found 16-bit adder carry in/out for signal <$n0001>.
Found 8-bit adder carry in/out for signal <$n0002>.
Found 1-bit 4-to-1 multiplexer for signal <c>.
Summary:
inferred 2 Adder/Subtractor(s).
inferred 1 Multiplexer(s).
Unit <addsub2> synthesized.
=========================================================================
HDL Synthesis Report
Macro Statistics
# Adders/Subtractors : 2
16-bit adder carry in/out : 1
8-bit adder carry in/out : 1
# Multiplexers : 1
1-bit 4-to-1 multiplexer : 1
=========================================================================
=========================================================================
* Advanced HDL Synthesis
*
=========================================================================
=========================================================================
Advanced HDL Synthesis Report
Macro Statistics
# Adders/Subtractors : 2
16-bit adder carry in/out : 1
8-bit adder carry in/out : 1
# Multiplexers : 1
1-bit 4-to-1 multiplexer : 1
=========================================================================
=========================================================================
* Low Level Synthesis
*
=========================================================================
Loading device for application Rf_Device from file '3s200.nph' in
environment C:\Xilinx.
Optimizing unit <addsub2> ...
Mapping all equations...
Building and optimizing final netlist ...
Found area constraint ratio of 100 (+ 5) on block addsub2, actual ratio
is 1.
=========================================================================
* Final Report
*
=========================================================================
Final Results
RTL Top Level Output File Name : addsub2.ngr
Top Level Output File Name : addsub2
Output Format : NGC
Optimization Goal : Speed
Keep Hierarchy : NO
Design Statistics
# IOs : 61
Cell Usage :
# BELS : 91
# LUT2 : 34
# LUT3 : 9
# MUXCY : 24
# XORCY : 24
# IO Buffers : 61
# IBUF : 35
# OBUF : 26
=========================================================================
Device utilization summary:
---------------------------
Selected Device : 3s200pq208-5
Number of Slices: 23 out of 1920 1%
Number of 4 input LUTs: 43 out of 3840 1%
Number of bonded IOBs: 61 out of 141 43%
=========================================================================
TIMING REPORT
NOTE: THESE TIMING NUMBERS ARE ONLY A SYNTHESIS ESTIMATE.
FOR ACCURATE TIMING INFORMATION PLEASE REFER TO THE TRACE REPORT
GENERATED AFTER PLACE-and-ROUTE.
Clock Information:
------------------
No clock signals found in this design
Timing Summary:
---------------
Speed Grade: -5
Minimum period: No path found
Minimum input arrival time before clock: No path found
Maximum output required time after clock: No path found
Maximum combinational path delay: 12.955ns
Timing Detail:
--------------
All values displayed in nanoseconds (ns)
=========================================================================
Timing constraint: Default path analysis
Total number of paths / destination ports: 1012 / 26
-------------------------------------------------------------------------
Delay: 12.955ns (Levels of Logic = 21)
Source: op (PAD)
Destination: c_out (PAD)
Data Path: op to c_out
Gate Net
Cell:in->out fanout Delay Delay Logical Name (Net Name)
---------------------------------------- ------------
IBUF:I->O 27 0.715 1.721 op_IBUF (op_IBUF)
LUT2:I1->O 2 0.479 1.040 bs<0>1 (bs<0>)
LUT2:I0->O 1 0.479 0.000 addsub2_y<0>lut (N4)
MUXCY:S->O 1 0.435 0.000 addsub2_y<0>cy
(addsub2_y<0>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub2_y<1>cy
(addsub2_y<1>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub2_y<2>cy
(addsub2_y<2>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub2_y<3>cy
(addsub2_y<3>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub2_y<4>cy
(addsub2_y<4>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub2_y<5>cy
(addsub2_y<5>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub2_y<6>cy
(addsub2_y<6>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub2_y<7>cy
(addsub2_y<7>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub2_y<8>cy
(addsub2_y<8>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub2_y<9>cy
(addsub2_y<9>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub2_y<10>cy
(addsub2_y<10>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub2_y<11>cy
(addsub2_y<11>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub2_y<12>cy
(addsub2_y<12>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub2_y<13>cy
(addsub2_y<13>_cyo)
MUXCY:CI->O 1 0.056 0.000 addsub2_y<14>cy
(addsub2_y<14>_cyo)
MUXCY:CI->O 1 0.265 0.976 addsub2_y<15>cy (e)
LUT2:I0->O 1 0.479 0.681 c_out1 (c_out_OBUF)
OBUF:I->O 4.909 c_out_OBUF (c_out)
----------------------------------------
Total 12.955ns (8.538ns logic, 4.418ns route)
(65.9% logic, 34.1% route)
*/
--
PabloBleyerKocik /
pablo /"It is a terrible thing to see and have no vision."
@bleyer.org / -- Helen Keller
Article: 99524Ben i was wrong when i said that the design didnt't work in all PC on our lab, but its rather didn't work for all but it did somehow on my PC but not with others, and that's the main problem i faced which forced me to re-design using the State machine design as described on Appendix B of PCI 3.0 Spec To add, the former design that i made based on your mini pci worked well on my pc only and other pc in our lab with the same motherboard. It worked because i was able to read/write to the registers of back-end device. >Also, in your simulation you have a config space read at address '1' >which should really be a read at 0 with byte enables. And you return >all '1's which would not be valid and could cause the problem I described >above with your BIOS. Sorry for not making the screenshot more readable, but that was 10h, i'm writing to BAR0 and reading it back. the resulting data is FFFFFF08 ( Memory and 256 bytes). ps. when BUS MASTER reads configuration especially the Status register w/c has the devsel timing, how long will it Assert IRDY#, because at this moment still doesn't know the devsel timing for this spefic Device? Young Leaf
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