Remove legacy codes in FPGA-Verilog

docs/source/arch_lang/circuit_model_examples.rst

@@ -231,7 +231,7 @@ SRAMs
 .. note:: The support SRAM modules should have a BL and a WL when the memory-bank-style configuration circuit is declared. Note that the WL should be the write/read enable signal, while BL is the data input.
 
 Logic gates
------
+-----------
 
 .. code-block:: xml
 

docs/source/arch_lang/circuit_modules.rst

@@ -98,3 +98,5 @@ Transistor level
     * **is_config_enable:** can be either ``true`` or ``false``. Only valid when ``is_global`` is true. Specify if this port controls a configuration-enable signal. This port is only enabled during FPGA configuration, and always disabled during FPGA operation. All the ``config_enable`` ports are connected to global configuration-enable voltage stimuli in testbenches.
 
 .. note::  Different types of ``circuit_model`` have different XML syntax, with which users can highly customize their circuit topologies. See refer to examples of ``circuit_model`` for more details.
+
+.. note:: Note that we have a list of reserved port names, which indicate the usage of these ports when building FPGA fabrics. Please do not use ``mem_out``, ``mem_inv``, ``bl``, ``wl``, ``blb``, ``wlb``, ``ccff_head`` and ``ccff_tail``.

docs/source/fpga_bitstream/file_organization.rst

@@ -1,4 +1,38 @@
 Bistream Output File Format
 ============================
 
-**Under Construction**
+FPGA-Bitstream can generate two types of bitstreams:
+* Generic bitstreams, where configuration bits are organized out-of-order in a database. We output the generic bitstream to a XML format, which is easy to debug. As shown in the following XML code, configuration bits are organized block by block, where each block could be a LUT, a routing multiplexer `etc`. Each ``bitstream_block`` includes two sets of information: 
+  - ``hierarchy`` represents the location of this block in FPGA fabric.
+  - ``bitstream`` represents the configuration bits affiliated to this block.
+
+.. code-block:: xml
+
+  <bitstream_block index="0">
+      <hierarchy>
+          <instance level="0" name="fpga_top"/>
+          <instance level="1" name="grid_clb_1_1"/>
+          <instance level="2" name="fle_0"/>
+          <instance level="3" name="lut4_0"/>
+      </hierarchy>
+      <bitstream>
+          <bit memory_port="mem_out[0]" value="1"/>
+          <bit memory_port="mem_out[1]" value="0"/>
+          <bit memory_port="mem_out[2]" value="1"/>
+          <bit memory_port="mem_out[3]" value="0"/>
+          <bit memory_port="mem_out[4]" value="1"/>
+          <bit memory_port="mem_out[5]" value="0"/>
+          <bit memory_port="mem_out[6]" value="1"/>
+          <bit memory_port="mem_out[7]" value="0"/>
+          <bit memory_port="mem_out[8]" value="1"/>
+          <bit memory_port="mem_out[9]" value="0"/>
+          <bit memory_port="mem_out[10]" value="1"/>
+          <bit memory_port="mem_out[11]" value="0"/>
+          <bit memory_port="mem_out[12]" value="1"/>
+          <bit memory_port="mem_out[13]" value="0"/>
+          <bit memory_port="mem_out[14]" value="1"/>
+          <bit memory_port="mem_out[15]" value="0"/>
+      </bitstream>
+  </bitstream_block>
+
+* Fabric-dependent bitstreams, where configuration bits are organized to be loadable to the configuration protocols of FPGAs. The bitstream just sets an order to the configuration bits in the database, without duplicating the database. OpenFPGA framework provides a fabric-dependent bitstream generator which is aligned to our Verilog netlists. The fabric-dependent bitstream can be found in autogenerated Verilog testbenches.

docs/source/fpga_bitstream/index.rst

@@ -1,5 +1,5 @@
 FPGA-Bitstream
-=============
+==============
 
 .. _fpga_bitstream:
    User Manual for FPGA Bitstream Generator

docs/source/fpga_verilog/func_verify.rst

@@ -5,20 +5,8 @@ If the --fpga_verilog_print_modelsim_autodeck option is selected, it is possible
 
 The point of the verification step is to check that the FPGA reproduces the right function. As illustrated in :numref:`fig_ModelSim`, inside of the red rectangle is the programming of the FPGA. Each prog clock cycle corresponds to one bit added to the scan-chain. Inside of the blue rectangle, we see that the prog clock is set to 0 and the operating clock is toggled. Two outputs are shown, benchmark and FPGA, and by checking the value on both of them, we know if the functionality is respected.
 
-
-
-
-
 .. _fig_ModelSim:
 
 .. figure:: ./figures/Verification_step.pdf
    :scale: 100%
    :alt: Functional Verification using ModelSim
-
-
-
-
-
-
-
-

docs/source/motivation.rst

@@ -26,11 +26,13 @@ This motivates us to generate the Verilog code of the architecture to enable a s
 
 In this manual, we present FPGA-Verilog. This extension enables the generation of a fully functional Verilog code enabling a deeper understanding of the architectures of the FPGAs. We introduce different options to this module to do the verification of the system. This will be presented in more depth in the FPGA-Bitstream section.
 
-The technical details can be found in our TVLSI'19 paper :cite:`XTang_TVLSI_2019`.
+The technical details can be found in our TVLSI'19 paper :cite:`XTang_TVLSI_2019` and FPL'19 paper :cite:`XTang_FPL_2019`.
 
 FPGA-Bitstream
 --------------
 
 To have the right functionality on top of the FPGA generated, it is necessary to have a Bitstream generation which programs the FPGA. For this reason, we generate a Bitstream and some testbenches in parallel which allow the user to do some functional verification of the system to make sure that the functionality is respected. This includes three different testbenches. First, the FPGA is configured then the clock runs with random patterns are generated to test the functionality. Secondly, the FPGA can be configured in parallel to the testbench itself to do a comparison of the signals and check the validity. Finally, the configuration can be skipped to directly have access to the functioning of the system and reduce the processing time.
 
 This will be explained in more depth in the FPGA-Bitstream section.
+
+The technical details can be found in our TVLSI'19 paper :cite:`XTang_TVLSI_2019` and FPL'19 paper :cite:`XTang_FPL_2019`.

docs/source/z_reference.bib

@@ -14,19 +14,6 @@ @INPROCEEDINGS{XTang_ICCD_2015
 ISSN={},
 month={Oct},}
 
-@ARTICLE{XTang_JETCAS_2018,
-author={X. Tang and E. Giacomin and G. De Micheli and P. Gaillardon},
-journal={IEEE Journal on Emerging and Selected Topics in Circuits and Systems},
-title={Post-P amp;R Performance and Power Analysis for RRAM-Based FPGAs},
-year={2018},
-volume={8},
-number={3},
-pages={639-650},
-keywords={Field programmable gate arrays;Random access memory;Analytical models;Delays;Resistance;Routing;Programmable logic arrays;resistive ram;simulation;system modeling;integrated circuit reliability},
-doi={10.1109/JETCAS.2018.2847600},
-ISSN={2156-3357},
-month={Sept},}
-
 @book{VBetz_Book_1999,
  editor = {Betz, Vaughn and Rose, Jonathan and Marquardt, Alexander},
  title = {Architecture and CAD for Deep-Submicron FPGAs},
@@ -36,31 +23,6 @@ @book{VBetz_Book_1999
  address = {Norwell, MA, USA},
 } 
 
-@article{XTang_TCAS1_2016,
-	title={{A Study on the Programming Structures for RRAM-based FPGA Architectures}},
-	author={X. Tang and Kim, Gain and Gaillardon, Pierre-Emmanuel and De Micheli, Giovanni},
-	journal={IEEE Transactions on Circuits and Systems I: Regular Papers},
-	volume={63},
-	number={4},
-	pages={503--516},
-	year={2016},
-	publisher={IEEE}
-}
-
-
-@ARTICLE{XTang_TCAS1_2017,
-	author={X. Tang and E. Giacomin and G. De Micheli and P. E. Gaillardon},
-	journal={IEEE Transactions on Circuits and Systems I: Regular Papers},
-	title={{Circuit Designs of High-Performance and Low-Power RRAM-Based Multiplexers Based on 4T(ransistor)1R(RAM) Programming Structure}},
-	year={2017},
-	volume={64},
-	number={5},
-	pages={1173-1186},
-	keywords={Delays;Logic gates;Multiplexing;Programming;Resistance;Routing;Transistors;Circuit design;high-performance;low-power;multiplexer;resistive memory},
-	doi={10.1109/TCSI.2016.2638542},
-	ISSN={1549-8328},
-	month={May},}
-
 @inproceedings{JLuu_FPGA_2011,
 	author = {Luu, Jason and Anderson, Jason Helge and Rose, Jonathan Scott},
 	title = {{Architecture Description and Packing for Logic Blocks with Hierarchy, Modes and Complex Interconnect}},
@@ -119,3 +81,17 @@ @ARTICLE{XTang_TVLSI_2019
   ISSN={1063-8210},
   month={March},
 }
+
+@INPROCEEDINGS{XTang_FPL_2019,
+author={X. {Tang} and E. {Giacomin} and A. {Alacchi} and B. {Chauviere} and P. {Gaillardon}},
+booktitle={2019 29th International Conference on Field Programmable Logic and Applications (FPL)},
+title={OpenFPGA: An Opensource Framework Enabling Rapid Prototyping of Customizable FPGAs},
+year={2019},
+volume={},
+number={},
+pages={367-374},
+keywords={field programmable gate arrays;logic design;reconfigurable architectures;software prototyping;OpenFPGA;FPGA architectures;semicustom design;XML-to-Prototype design flow;Verilog netlists;FPGA fabric;XML language;VTR framework;production-ready layouts;fully-optimized commercial products;data processing applications;Field Programmable Gate Arrays;programmable accelerators;computing systems;Verilog-to-Bitstream generator;Field programmable gate arrays;Computer architecture;Hardware design languages;XML;Microprocessors;Layout;Libraries;FPGA;Verilog generator;Bitstream generation;Semi Custom Designed FPGA},
+doi={10.1109/FPL.2019.00065},
+ISSN={1946-147X},
+month={Sep.},}
+

openfpga_flow/VerilogNetlists/dpram.v

@@ -1,7 +1,7 @@
 //-----------------------------------------------------
 // Design Name : dual_port_ram
-// File Name   : memory_wrapper.v
-// Function    : Dual port RAM 64x2048 
+// File Name   : dpram.v
+// Function    : Dual port RAM 32x1024 
 // Coder       : Aurelien
 //-----------------------------------------------------
 
@@ -41,13 +41,13 @@ module dual_port_sram (
 
 	assign d_out = internal;
 
-	always @(negedge wclk) begin
+	always @(posedge wclk) begin
 		if(wen) begin
 			ram[waddr] <= data_in;
 		end
 	end
 
-	always @(negedge rclk) begin
+	always @(posedge rclk) begin
 		if(ren) begin
 			internal <= ram[raddr];
 		end

openfpga_flow/misc/OpenFPGA_lib/brams.txt

@@ -0,0 +1,36 @@
+bram $__MY_DPRAM
+  init 0
+  abits 10
+  dbits 32
+  groups 2
+  ports  1  1
+  wrmode 1  0
+  enable 1  1
+  transp 0  0
+  clocks 1  1
+  clkpol 1  1
+endbram
+
+bram $__MY_SPRAM
+  init 0
+  abits 10
+  dbits 32
+  groups 2
+  ports  1  1
+  wrmode 1  0
+  enable 1  0
+  transp 0  0
+  clocks 1  1
+  clkpol 1  1
+endbram
+
+match $__MY_DPRAM
+  min efficiency 0
+  make_transp
+  or_next_if_better
+endmatch
+
+match $__MY_SPRAM
+  min efficiency 0
+  make_transp
+endmatch

openfpga_flow/misc/OpenFPGA_lib/brams_map.v

@@ -0,0 +1,44 @@
+module $__MY_DPRAM (
+	output[31:0] B1DATA,
+	input CLK1,
+	input[9:0] B1ADDR,
+	input[9:0] A1ADDR,
+	input[31:0] A1DATA,
+	input A1EN,
+	input B1EN );
+
+	generate
+		dpram #() _TECHMAP_REPLACE_ (
+			.clk		(CLK1),
+			.wen		(A1EN),
+			.waddr		(A1ADDR),
+			.d_in		(A1DATA),
+			.ren		(B1EN),
+			.raddr		(B1ADDR),
+			.d_out		(B1DATA) );
+	endgenerate
+
+endmodule
+
+
+
+module $__MY_SPRAM (
+	output[31:0] B1DATA,
+	input CLK1,
+	input[9:0] B1ADDR,
+	input[9:0] A1ADDR,
+	input[31:0] A1DATA,
+	input A1EN );
+
+	generate
+		dpram #() _TECHMAP_REPLACE_ (
+			.clk		(CLK1),
+			.wen		(A1EN),
+			.waddr		(A1ADDR),
+			.d_in		(A1DATA),
+			.ren		(1'b1),
+			.raddr		(A1ADDR),
+			.d_out		(B1DATA) );
+	endgenerate
+
+endmodule

openfpga_flow/misc/OpenFPGA_lib/cells_sim.v

@@ -0,0 +1,62 @@
+module dpram (
+	input clk,
+	input wen,
+	input ren,
+	input[9:0] waddr,
+	input[9:0] raddr,
+	input[31:0] d_in,
+	output[31:0] d_out );
+
+		dual_port_sram memory_0 (
+			.wclk		(clk),
+			.wen		(wen),
+			.waddr		(waddr),
+			.data_in	(d_in),
+			.rclk		(clk),
+			.ren		(ren),
+			.raddr		(raddr),
+			.d_out		(d_out) );
+
+endmodule
+
+module dual_port_sram (
+	input wclk,
+	input wen,
+	input[9:0] waddr,
+	input[31:0] data_in,
+	input rclk,
+	input ren,
+	input[9:0] raddr,
+	output[31:0] d_out );
+
+	reg[31:0] ram[1023:0];
+	reg[31:0] internal;
+
+	assign d_out = internal;
+
+	always @(posedge wclk) begin
+		if(wen) begin
+			ram[waddr] <= data_in;
+		end
+	end
+
+	always @(posedge rclk) begin
+		if(ren) begin
+			internal <= ram[raddr];
+		end
+	end
+
+endmodule
+
+module adder(
+	input cin,
+	input a,
+	input b,
+	output cout,
+	output sumout );
+
+
+	assign sumout = a ^ b ^ cin;
+	assign cout = (a & b) | ((a | b) & cin);
+
+endmodule