Are their faster bitstreams in the works or is the 200mh/s going to be the top for awhile? We are working on the next revision of the firmware, dubbed Overclocker firmware, which will allow overclocking (or downclocking) the FPGA. This should provide a boost over the rated frequency if the board is kept sufficiently cool. |
|
|
|
Ok the log3 version works fine. Wonderful! Something I had not noticed before is I recieve an error about "Warning: Feature LogicLock is only available with a valid subscription license. You can purchase a software subscription to gain full access to this feature." when I compile the project. That warning should only come up if the project uses an IP core that is LogicLock'd. The mining firmware obviously doesn't so ... perhaps you fiddled with some strange setting? Or it might say it for no reason at all... I put the project I used up on the public GitHub repo, so you can try compiling that: https://github.com/progranism/Open-Source-FPGA-Bitcoin-Miner/tree/master/projects/BeMicroJust pull the whole repo and compile the project under that BeMicro folder. |
|
|
|
I am using the BeMicro-SDK, The tcl mining script, and unoptimized 115 pipelined with the cyclone IV chip programmed in to match my board. Wow, Arrow really worked hard to make it extraordinarily difficult to find the right downloads for the BeMicro.  Did you adjust the design to connect to the 50MHz clock on pin E1? I took the time to set up a project and compile some firmware for you. Here is the SOF file: http://www.bitcoin-mining.com/bemicro_loop4_50MHz_3MH_20120219a.sofPlease try that firmware, and then try the mining script again. If you can, take some screenshots of the mining script starting, running for a little bit, and any errors you might encounter. Also, that firmware will only find a share every 24 minutes or so (on average). I modified the firmware to use LOOP_LOG2=3, which runs at 6MH/s (twice as fast): http://www.bitcoin-mining.com/bemicro_loop3_50MHz_6MH_20120219a.sofShould work just as well, but find a share every 12 minutes (on average). |
|
|
|
|
Hello Askit2! It is unclear to me what development board you are currently using. Are you using a DE0-Nano or a different board?
|
|
|
|
Neat! Thank you for digging up the link. Looks like the "Irvine" event is actually up in Orange . See you guys there! |
|
|
|
Fantastic work, molecular! I freed up a Linux machine last week for my lab, so I can certainly give your guide a try  [UrJtag ... ] maybe we can even program with this tool, I don't know. Anyone? Okay, here's the deal with UrJTAG. I wanted to completely replace the ISE requirement on these X5000 boards by using UrJTAG which works on multiple platforms, at least Linux and Windows. Using UrJTAG would completely eliminate the need to use ISE for mining, because it can both program the FPGA and communicate with it to push and pull work. Now, UrJTAG states explicitly in their documentation that support for Xilinx Platform Cables is experimental and slow. I figured I didn't have any other options, so I gave it a try anyway. Long story short, I can program an FPGA using UrJTAG and my Platform Cable, but it takes ten or more minutes to do so. I also have terrible trouble with the drivers, which need to be re-installed every time I boot my system. I have not given up on using UrJTAG. I dug into its code for xpc_ext. It's fairly simple code, and it looks like the reason why it's so slow is because they're using a slow, GPIO bit-bang mode of the platform cable, whereas ISE would normally use special JTAG specific modes. So with some hard work it might be possible to fix UrJTAG's support of xpc_ext, and I have that on my TODO list. Don't expect it next or week or anything like that; I have a lot to clear off my plate and the work is non-trivial. But it would be kind of fun to get working |
|
|
|
A quick guide how to synthesize a project in ISE WebPack 13.2 would also be very helpful. And for Altera users how to do it in Quartus...
I'm trying for 4 hours at least and nothing. Errors, errors... I've tried to synthesize LX150_makomk_Test. Becuse WebPack have limits I've change LOOP_LOG2 to 1. Any help?
TIA. For ISE you simply load the xise project file, make sure fpgaminer_top is selected in the Hierarchy in the upper-left, and then double click "Generate Programming File" in Processes in the lower-left. For Quartus you can just load the project and press Ctrl+L. There should also be a menu options under Processing. Let me know what errors you are getting or what the specific trouble is. Please note that the LX150_makomk_Test project won't compile on WebPack. You'd have to target a different device (LX75 or below). |
|
|
|
Maybe someone have an idea what would happen if file generated for LX75 I will try to load to LX150? Configuration data for an LX75 is not compatible with an LX150, so no matter what you do it won't work. If you attempt to load a normally generated bitstream from an LX75 onto an LX150, configuration will immediately fail. Technically you can hack the bitstream and force it to load, but A) Xilinx says it may "damage your hardware if you do", and B) as states above the configuration data isn't compatible so you accomplish nothing. I should note that boards like the X6x00 do not require ISE to load firmware into the FPGA. You'd only need ISE if you wish to compile your own firmware and bitstreams. It's unfortunate, but that's how Xilinx's licensing works :/ They offer a 30-day trial which I think lets you compile for any device. |
|
|
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello ztex, I felt it best to bring this to the public forum. August 29th, 2011 In your reply PM to me, you stated that none of your Verilog code is a derivative of my work. However, I am very concerned by many similarities between your newly released Verilog code, and my GPL3 code which has been around since May 20th, 2011. I hope these are just coincidences, but to express my concerns I have listed details below. 1) The use of the term golden_nonce is unique to me, and has not to my knowledge, nor the knowledge of Google, ever been used by anyone else. It appears several times in your code. 2) Your use of an appended _w is unique to my Verilog coding style. 3) Your use of a monolithic localparam named Ks in sha256_pipes.v, with the constants occurring in reverse order using the concat operator is unique to my project. 4) The use of a define named IDX is an exact duplicate of my usage, again unique to my coding style. I am listing an exact copy of your code below, as of this date, and links to code belonging to my github repo. Please note that there are many variations of the code available on my repo, and also note that much of the code on my repo is contributed by myself, and various other wonderful developers. miner128.v/*!
btcminer -- BTCMiner for ZTEX USB-FPGA Modules: HDL code: double hash miner
Copyright (C) 2011 ZTEX GmbH
http://www.ztex.de
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License version 3 as
published by the Free Software Foundation.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, see http://www.gnu.org/licenses/.
!*/
module miner128 (clk, reset, midstate, data, golden_nonce, nonce2, hash2);
parameter NONCE_OFFS = 32'd0;
parameter NONCE_INCR = 32'd1;
parameter NONCE2_OFFS = 32'd0;
input clk, reset;
input [255:0] midstate;
input [95:0] data;
output reg [31:0] golden_nonce, hash2, nonce2;
reg [31:0] nonce;
wire [255:0] hash;
wire [31:0] hash2_w;
sha256_pipe66 p1 (
.clk(clk),
.state(midstate),
.state2(midstate),
.data({384'h000002800000000000000000000000000000000000000000000000000000000000000000000000000000000080000000, nonce, data}),
.hash(hash)
);
sha256_pipe62 p2 (
.clk(clk),
.data({256'h0000010000000000000000000000000000000000000000000000000080000000, hash}),
.hash(hash2_w)
);
always @ (posedge clk)
begin
if ( reset )
begin
nonce <= 32'd129 + NONCE_OFFS;
nonce2 <= NONCE_OFFS + NONCE2_OFFS;
golden_nonce <= 32'd0;
end else begin
nonce <= nonce + NONCE_INCR;
nonce2 <= nonce2 + NONCE_INCR;
if ( hash2 == 32'ha41f32e7 )
begin
golden_nonce <= nonce2;
end
end
hash2 <= hash2_w;
end
endmodule
/*!
btcminer -- BTCMiner for ZTEX USB-FPGA Modules: HDL code: hash pipelines
Copyright (C) 2011 ZTEX GmbH
http://www.ztex.de
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License version 3 as
published by the Free Software Foundation.
This program is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, see http://www.gnu.org/licenses/.
!*/
`define IDX(x) (((x)+1)*(32)-1):((x)*(32))
`define E0(x) ( {{x}[1:0],{x}[31:2]} ^ {{x}[12:0],{x}[31:13]} ^ {{x}[21:0],{x}[31:22]} )
`define E1(x) ( {{x}[5:0],{x}[31:6]} ^ {{x}[10:0],{x}[31:11]} ^ {{x}[24:0],{x}[31:25]} )
`define CH(x,y,z) ( (z) ^ ((x) & ((y) ^ (z))) )
`define MAJ(x,y,z) ( ((x) & (y)) | ((z) & ((x) | (y))) )
`define S0(x) ( { {x}[6:4] ^ {x}[17:15], {{x}[3:0], {x}[31:7]} ^ {{x}[14:0],{x}[31:18]} ^ {x}[31:3] } )
`define S1(x) ( { {x}[16:7] ^ {x}[18:9], {{x}[6:0], {x}[31:17]} ^ {{x}[8:0],{x}[31:19]} ^ {x}[31:10] } )
module sha256_pipe_base ( clk, state, data, out );
parameter STAGES = 64;
input clk;
input [255:0] state;
input [511:0] data;
output [255:0] out;
localparam Ks = {
32'h428a2f98, 32'h71374491, 32'hb5c0fbcf, 32'he9b5dba5,
32'h3956c25b, 32'h59f111f1, 32'h923f82a4, 32'hab1c5ed5,
32'hd807aa98, 32'h12835b01, 32'h243185be, 32'h550c7dc3,
32'h72be5d74, 32'h80deb1fe, 32'h9bdc06a7, 32'hc19bf174,
32'he49b69c1, 32'hefbe4786, 32'h0fc19dc6, 32'h240ca1cc,
32'h2de92c6f, 32'h4a7484aa, 32'h5cb0a9dc, 32'h76f988da,
32'h983e5152, 32'ha831c66d, 32'hb00327c8, 32'hbf597fc7,
32'hc6e00bf3, 32'hd5a79147, 32'h06ca6351, 32'h14292967,
32'h27b70a85, 32'h2e1b2138, 32'h4d2c6dfc, 32'h53380d13,
32'h650a7354, 32'h766a0abb, 32'h81c2c92e, 32'h92722c85,
32'ha2bfe8a1, 32'ha81a664b, 32'hc24b8b70, 32'hc76c51a3,
32'hd192e819, 32'hd6990624, 32'hf40e3585, 32'h106aa070,
32'h19a4c116, 32'h1e376c08, 32'h2748774c, 32'h34b0bcb5,
32'h391c0cb3, 32'h4ed8aa4a, 32'h5b9cca4f, 32'h682e6ff3,
32'h748f82ee, 32'h78a5636f, 32'h84c87814, 32'h8cc70208,
32'h90befffa, 32'ha4506ceb, 32'hbef9a3f7, 32'hc67178f2
};
genvar i;
generate
for (i = 0; i <= STAGES; i = i + 1) begin : S
wire [479:0] w_data;
wire [223:0] w_state;
wire [31:0] w_t1, w_data14;
if(i == 0)
sha256_stage0 #(
.K_NEXT(Ks[`IDX(63)]),
.STAGES(STAGES)
) I (
.clk(clk),
.i_data(data),
.i_state(state),
.o_data(w_data),
.o_state(w_state),
.o_t1(w_t1),
.o_data14(w_data14)
);
else
sha256_stage #(
.K_NEXT(Ks[`IDX((127-i) & 63)]),
.STAGES(STAGES)
) I (
.clk(clk),
.i_data(S[i-1].w_data),
.i_state(S[i-1].w_state),
.i_t1(S[i-1].w_t1),
.i_data14(S[i-1].w_data14),
.o_data(w_data),
.o_state(w_state),
.o_t1(w_t1),
.o_data14(w_data14)
);
end
endgenerate
reg [31:0] state7;
always @ (posedge clk)
begin
state7 <= S[STAGES-1].w_state[`IDX(6)];
end
assign out[255:224] = state7;
assign out[223:0] = S[STAGES].w_state;
endmodule
module sha256_pipe66 ( clk, state, state2, data, hash );
input clk;
input [255:0] state, state2;
input [511:0] data;
output reg [255:0] hash;
wire [255:0] out;
sha256_pipe_base #( .STAGES(64) ) P (
.clk(clk),
.state(state),
.data(data),
.out(out)
);
always @ (posedge clk)
begin
hash[`IDX(0)] <= state2[`IDX(0)] + out[`IDX(0)];
hash[`IDX(1)] <= state2[`IDX(1)] + out[`IDX(1)];
hash[`IDX(2)] <= state2[`IDX(2)] + out[`IDX(2)];
hash[`IDX(3)] <= state2[`IDX(3)] + out[`IDX(3)];
hash[`IDX(4)] <= state2[`IDX(4)] + out[`IDX(4)];
hash[`IDX(5)] <= state2[`IDX(5)] + out[`IDX(5)];
hash[`IDX(6)] <= state2[`IDX(6)] + out[`IDX(6)];
hash[`IDX(7)] <= state2[`IDX(7)] + out[`IDX(7)];
end
endmodule
module sha256_pipe62 ( clk, data, hash );
parameter state = 256'h5be0cd191f83d9ab9b05688c510e527fa54ff53a3c6ef372bb67ae856a09e667;
input clk;
input [511:0] data;
output [31:0] hash;
wire [255:0] out;
sha256_pipe_base #( .STAGES(61) ) P (
.clk(clk),
.state(state),
.data(data),
.out(out)
);
assign hash = out[`IDX(4)];
endmodule
module sha256_pipe65 ( clk, state, data, hash );
input clk;
input [255:0] state;
input [511:0] data;
output [255:0] hash;
wire [255:0] out;
sha256_pipe_base #( .STAGES(64) ) P (
.clk(clk),
.state(state),
.data(data),
.out(out)
);
assign hash = out;
endmodule
module sha256_stage0 ( clk, i_data, i_state, o_data, o_state, o_t1, o_data14 );
parameter K_NEXT = 32'd0;
parameter STAGES = 64;
input clk;
input [511:0] i_data;
input [255:0] i_state;
output reg [479:0] o_data;
output reg [223:0] o_state;
output reg [31:0] o_t1, o_data14;
wire [31:0] s0;
always @ (posedge clk)
begin
o_data <= i_data[511:32];
o_state <= i_state[223:0];
o_t1 <= i_state[`IDX(7)] + i_data[`IDX(0)] + K_NEXT;
o_data14 <= `S0( i_data[`IDX(1)] ) + i_data[`IDX(0)];
end
endmodule
module sha256_stage ( clk, i_data, i_state, i_t1, i_data14, o_data, o_state, o_t1, o_data14 );
parameter K_NEXT = 32'd0;
parameter STAGES = 64;
input clk;
input [31:0] i_t1, i_data14;
input [479:0] i_data;
input [223:0] i_state;
output reg [479:0] o_data;
output reg [223:0] o_state;
output reg [31:0] o_t1, o_data14;
wire [31:0] t1 = `E1( i_state[`IDX(4)] ) + `CH( i_state[`IDX(4)], i_state[`IDX(5)], i_state[`IDX(6)] ) + i_t1;
wire [31:0] t2 = `E0( i_state[`IDX(0)] ) + `MAJ( i_state[`IDX(0)], i_state[`IDX(1)], i_state[`IDX(2)] );
wire [31:0] data14 = `S1( i_data[`IDX(13)] ) + i_data[`IDX(8)] + i_data14;
always @ (posedge clk)
begin
o_data[447:0] <= i_data[479:32];
o_data[`IDX(14)] <= data14;
o_state[`IDX(0)] <= t1 + t2;
o_state[`IDX(1)] <= i_state[`IDX(0)];
o_state[`IDX(2)] <= i_state[`IDX(1)];
o_state[`IDX(3)] <= i_state[`IDX(2)];
o_state[`IDX(4)] <= i_state[`IDX(3)] + t1;
o_state[`IDX(5)] <= i_state[`IDX(4)];
o_state[`IDX(6)] <= i_state[`IDX(5)];
o_t1 <= i_state[`IDX(6)] + i_data[`IDX(0)] + K_NEXT;
o_data14 <= `S0( i_data[`IDX(1)] ) + i_data[`IDX(0)];
end
endmodule
Please do not interpret this as me calling you a liar. You have obviously put a lot of work into your code and made numerous enhancements. I honestly wish you the best success with it. These numerous similarities just set off a lot of alarm bells for me and I hope you understand that. Help me to figure out why my coding style has leaked into your code and I will feel a lot better. Thank you, ~fpgaminer NOTE: GPG signed based on a plain-text copy of the text above. Just copy-paste the plain-text as it appears on the forum, so that BBCODE formatting is not included, to perform GPG signature verification. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (MingW32) iQIcBAEBAgAGBQJOXCZNAAoJEFFoGj2A5YKR1iYP/11I9Vo0FnxBrXdDGKfh68Ms gsDsaJkYRsLXFvKHONy19wdVdgcN3T+UpliypTU8c0DXm/rUM0vYNQxBkd59gOv+ 9cDPljLlu1oGz36hwgRwdrXKmEwodtlhcoKE7cFqnMFVCn72VSxJDu33pKMGlZPy Ea/NNonjJfxgTjQMOYtNevGsEe0iDAilJZ93RCUK2qSzWo1xT9hP+kjt5jyGQTNe k1tlz1YSPk+HWnOlb6LTx7Bf6MAaM8P7L0XI20JSRBvlEkieLgMYeBXFtKbgBtv5 4vy2Ws+BtzQyp8Yu7AmHFvx5n+b7iTnuGAP8D1iIUmvUHo1vroikvd8QoHAdGX+y 3hfHYcLfb6CN25lAhQsoY0PJVb5EWYm5KIaQiijJnzx8Ks2T85eN6LVQz26m9h9w P/0Sd9ySHCfeufhNVBh1zE+/w7HrRvlk2f/sT8CkxmQtOIY1tUIWKEb7P2GDdOMz 2UFgczxinRkoqG5QUdGGhC0pAoy4BptIKvpZmIFlXL0A3Y22sGldhmsKR45Bic67 iDmG+fyPf7HJRrkjY0Khv2eG/KlmBl5wu+LHZXRn7K8xS2cGR6Jj1NvdZyKafiKW zjIfqbu08tcr3ecghQGkRRpf9xr9SARjxqC9ACJFVxk+4ig/E9gYKhwUTpAnCgAt IAZUr+6syZkOImPXgSBz =X/vX -----END PGP SIGNATURE----- |
|
|
|
Is that really necessary to run the mining environment for the end user? I thought the idea of a FGPA was that it does in hardware what would otherwise have to implemented in software. The X6000 and X6500 boards will not require an ISE installation at all. I am writing the software to control these latest boards, and it will be very light weight. Also, I forgot to inquire. Would this FGPA miner afford any advantage towards R&D of an asic based solution? Is there any/much benefit of having a good FGPA based design to leverage a future asic device? Just out of curiosity. It most certainly does. In fact, there are many companies that can take an FPGA design and convert it to ASIC. |
|
|
|
I've been discussing with jonand about building a cluster of cheap FPGAs, and I've got the basic idea working: Very, very cool! |
|
|
|
No probs. This baby's going to be bolted to a set of solar panels. So low voltage from go to whoa. If you hook some of these mining boards up to solar panels, I definitely want pics  Very cool. |
|
|
|
A getwork request returns a Target (256-bits), Hash1 (256-bits), Midstate (256-bits), and Data (1024-bits). A SHA-256 hash needs two pieces of information, a 256-bit starting state, and 512-bits of data. It returns the resulting 256-bit hash. Here are the steps for a Bitcoin Hash: data = highest 512-bits of Data
for nonce in range(0, 2**32):
4th 32-bit word of data = nonce
hash = sha256(Midstate, data)
hash = sha256(Sha256InitialState, Hash1 << 256 | hash)
if hash <= Target:
Send a result back to the pool server or bitcoind
Note that Sha256InitialState is a 256-bit number defined by the SHA-256 standard. For FPGA mining, we assume that Hash1 is always the same (which it is), and that Target is always 0x00000000_FFFFFFFF_..._FFFFFFFF (which it is, for pool mining). As you can see in the first line of the pseudo-code above, only the last 512-bits of Data are used for hashing in this algorithm. Also, everything after the 4th 32-bit word of data is always the same. So, after all is said and done, the FPGA only needs the 256-bit Midstate, and 96-bits of Data. It then returns any 32-bit nonces that give us a hash <= 0x00000000_FFFFFFFF_..._FFFFFFFF. I've seen the wiki that says what goes in to a block header hash Than I should note that the 1024-bit Data value returned by getwork is actually just the block header, padded to 1024-bits. It's padded using SHA-256's padding algorithm. Check the SHA-256 wiki page if you are interested. |
|
|
|
My god makomk, how did you work out how to talk to altsource_probes? Debug the protocol? I will certainly be reading over that code today  Fantastic work. I'll have to see if Altera provides something similar to BSCAN_SPARTAN6, though, which should make the whole thing a lot easier. Only problem with the UrJTAG Python code is that pexpect is UNIX specific. There's a Windows port called wexpect I have been playing with. Its project on Google Code is inaccessible at the moment, for reasons unknown. The random wexpect.py file I found lying around some dusty corner of the internet works, but has a few bugs I had to work around. It's a real shame. UrJTAG is a nice program. Perhaps it would be worthwhile to write a SWIG based wrapper around all of its (apparently undocumented) C API. |
|
|
|
Hmm, I think I must be missing something. How is it possible that the estimation for 20 orders was $385 and now with 42 pre-orders the $420 is still right? Is it only due to the "order" ↔ "pre-order" difference, or are there more reasons? Mind you, I'm fine with that, just a bit surprised about the difference. The X6000 and X6500 boards are being designed and tweaked as we speak, as well as the logistics of fulfilling orders. Consider those ballpark figures, rough estimations based on the information we have at hand. Everyone is working diligently to get good price quotes, but it's a little bit difficult when the technology is still in flux It's like trying to figure out how much your new PC will cost, with an ever changing landscape of discounts and rebates, and you're still waiting for your last paycheck to clear before deciding whether you want blue or red LED fans |
|
|
|
There are ways to get the critical path down to a single 2-input 32 bit adder.
If you think carefully about what you're building. You want 3-input adders on 6 series Spartans, not 2-input. And yes, of course you can reduce the critical path to a single adder, but it requires an immense quantity of registers. And before you suggest it, don't tell me to run the FPGA faster to avoid extra pipeline registers . Spartan-6 isn't designed to run faster than ~250MHz. The memory doesn't run faster than that, and I think even the DSPs top out at that level. |
|
|
|
fizzisist: Yeah, I doubt anything I write now will ultimately be used as-is, but it will likely make good ground-work, and heck it shouldn't take me that long. The Python side of things will probably be the most useful If the code doesn't end up getting used, add it to my pile of incomplete hobby projects |
|
|
|
idk, I suggested the chip because I assumed gates are gates, no matter on which fpga they are. So I did some comparison.
This wasn't meant as a critique or that you choose the wrong chip, just me trying to help Your help is appreciated, and it's always good to learn about new options. A lot of FPGA products will list their gate count in promotional material, but gates are completely meaningless on an FPGA so it is just a marketing "scam."  Took Xilinx a few generations to stop that nonsense and start listing their products in terms of 4-LUTs. |
|
|
|
PC motherboards and graphics cards have similar power supply requirements, and they're definitely available for below $200... The effect volume has on component price blows my mind too. It's really quite unfair, but that's supply and demand for ya :/ I'm happy to report to the thread that I just ordered my FPGA miner. Congrats! Who wants to chisel that into the Bitcoin history book?  |
|
|
|
The plan is to use the MCU in a configuration similar to that described on page 38 of ug380.pdf to both program the FPGAs and for communication. To clarify, I think you mean page 26, where they show an MCU hooked up to the FPGA for Slave Serial Mode Configuration. Correct? And then the MCU will also be hooked up to a SPI bus going to both FPGAs (on general IO pins), with the MCU as master. Correct? What I can do is hook up my Launchpad to 4 GPIO pins on the Spartan-6 LX150T dev kit, and develop all of the SPI communication portion of the code. However, I don't believe I have access to the pins on this board necessary for Slave Serial Mode Configuration. So, I wouldn't be able to code the MSP430 to load the bitstream into the FPGA. Besides that, I will probably experiment with having the MSP430 talk to the JTAG port of my devkit. That isn't directly applicable to your design but it will provide the ground work for getting the bitstream over USB to the MCU, and the general flow of loading it into an FPGA. Unless someone else has some way of testing Slave Serial Mode Configuration, you may have to actually build the board before anyone can write and test that side of the code. Just throwing this out there, but if I can get my MSP430 to load a bitstream into the FPGA through JTAG, would it perhaps make sense to switch the programming interface on your design to that? |
|
|
|
|
Show Posts
