User Profile
BrianSune_Froum
ContributorJoined 4 years ago
User Widgets
Contributions
FPGA simulation and real HW behavior discrepancy
Dear Altera Quartus 18.1 sim lib could try 20.1 or newer but not sure this is due to Quartus version as it is sim lib. I am encounter an unexplainable experiment result that contradicts simulation and real HW. Background when interfacing a DQS DQ readout a IDDR with CCD sync flops are used. For these primitives, it should expected 1 + 2 and clock +ve edge should expect data push out. [A] This can simply considered as early push out but it should not act as such. With the use of "__ALTERA_STD__METASTABLE_SIM" we expected some metastable on the output. [B] Now things are more reasonable where 2 +ve clocks are expected. If we consider a full data w/o xx, things become unrecognizable. [C] The most interesting part when apply on real HW, it do produce correct data and the latencies do obeyed. altddio_in#( .intended_device_family ( "Cyclone IV E" ), .invert_input_clocks ( "ON" ), .lpm_hint ( "UNUSED" ), .lpm_type ( "altddio_in" ), .power_up_high ( "OFF" ), .width ( 8 ) )ddi_d_l( .aclr (reset), .datain (foo[7:0]), .inclock (bar[0]), .dataout_h (foobar_h[0+:8]), .dataout_l (foobar_l[0+:8]), .aset (1'b0), .inclocken (1'b1), .sclr (1'b0), .sset (1'b0) ); + altera_std_synchronizer_bundle#( .width (foobar_bw *2), .depth (2) )async_flops( .clk (clock), .reset_n (~reset), .din (foobar), .dout (foobar_ccd) );NIOS-II NOR-Flash boot Queries Issues
Dear Altera, Brian here, and there is a very unclear documentation on consolidation the NIOS-II firmware. According to "an-736-nios-ii-processor-booting-from-altera-serial-flash-epcq" We are supposed to use serial flash controller II with EPCQ/NOR-Flash variant. While under that document there are no clear mentioning how to deal with CPU speed > 25/50M. Issue 1: clock feeding > 50M will not work? Issue 2: What happen if cross-clock is applied and the build setup? It is understand that cross-clock-bridge can be used but no address span explanations are given to the documentation. Meantime, with only 50M or 25M global clock the CPU somehow considered as ultra-slow! So this documentation or the IP itself become completely kind of unpractical. Apart from the global clock speed, it is also understand that the limitations are due to the internal oscillation clock speed, which means the IP should provide cross-clock or high<->low clock buffering. Result: It somehow work on our side but unsure thats the correct procedure as what it should. Any good full setup steps and procedures would be nice so others can follow w/o any hesitation. Thanks, Brian
