One other post mentioned that they also believe the key displays are 32X32. My 128X128 was a number pulled from the nether regions. Although, as others have also pointed out, I completely neglected color depth. So, it probably washes out anyway.
That's a good point. Let's say they want 10 frames per second on each key and there are about 100 keys (rounding to make the calculation a little easier). If the resolution of each display is 128 pixels X 128 pixels, that's 16,384 pixels per display * 100 displays * 10 fps. That's 16,384,000 pixels that need to be touched each seconds. 16.384MHz isn't that fast. You could easily take a low cost FPGA (Xilinx Spartan/Altera Cyclone) and implement logic running four times that speed. So, I guess I'm back to believing it's possible.
I'd expect that to be unlikely only because I'd expect the refreah rate for the key displays to be very low. In order to get the hardware cost down, I expect there will be a lot of sharing of the logic used to update the displays. As a result, it could take on the order of seconds to update the display of a given key.
This is perfectly acceptable for the main function of a keyboard where waiting a couple seconds to load a new key layout isn't big deal (especially since the app won't load instantly anyway).
I don't get why people care that much about the team and player names. Dump the money required to license that garbage and diehard fans will do it anyway.
Is not gameplay the thing? That's where the real problem is. "Gary," the avid Madden fan mentioned in Greg Costikyan's blog, is absolutely correct--there's very little difference from year-to-year in the actual gameplay. I'm an NCAA Football fan. I did not buy the 2005 edition because the additions in the 2005 edition weren't that big of a deal. I might pick it up when there's a used copy for $20, but I feel no urgency.
I'll have a ton of fun with randomly generated player names and great gameplay. A static game with graphical facelifts from time-to-time and NFL player names will beg me to spend my money elsewhere.
While I can do without the condescending tone (I know that some current will flow even if the resistance is "large." It becomes a resistive divider. Even if you have 1 Ohm and 1 Megaohm, the 1 Megaohm path will carry a small amount of current.), I think I now understand your point.
The contention, then, is that since all paths start and end at the same points, all of them are in parallel with each other.
The first observation is to say that you have symmetry in this problem. You can find a path that goes up and the right that's 4 Ohms and a path that goes down and to the right that's 4 Ohms. Those two 4 Ohm paths are in parallel with each other and have an equivalent resistance of 2 Ohms. You can continue to do that for 5 Ohms, 6 Ohms, etc. And, since the pairs of parallel paths are the same value, the effect is to halve the resistance. So, you have 4/2=2, 5/2=2.5, 6/2=3, etc.
The next observation is that these paths are still in paralle with each other. This results in the equivalent resistance of 2\\5/2\\3\\7/2 etc. where I'm using \\ to mean "in parallel with." I'm going to assume you can find paths down to the base resistance of 1 Ohm. (Can we find a path with 1/2 Ohm resistance?) The 1 Ohm paths yield an equivalent resistance of 1/2 Ohms; Two 2 Ohnm paths yield an equivalent resistance of 1 Ohms, and so on. The pattern that emerges is:
I think your arguement adds an additional assumption--that there are infinitely many knights moves taken. The original problem does not state that. The question stated, "what is the resistance between two nodes that are a knight's move away?" The question did not state "N knight's moves away" or the like.
I'll pose another question, what is the resistance across any single resistor in that lattice? According to you, the resistance is still an infinite series since you can take an infinite number of paths between those two points.
I think the assumption in my set up and solution is that this is the only "closed circuit." In other words, I'm assuming the resistance for all other paths is infinite (nothing else is connected), and, therefore, you'll measure the resistance only across the resistor network that I "drew." So, it's not the resistance from the starting point to the knight's move away point for all possible paths since the resistance of any other path is infinite.
Your assumptions are leading you down a path like that discussed here http://mathworld.wolfram.com/ResistorNetwork.html.
I don't think you're drawing the diagram of the problem correctly. You're finding the resistance between two points defined by the knight's move ("two squares straight and one square to the side" http://chess.about.com/library/ble132kn.htm). As a result, the resistance is definately not infinite.
Each square of the infinite chess board has a resistor. Therefore, the squares involved in te knight's move look like this:
--+--R--+--R--+--R--+--B | | | | R R R R | | | | A--+--R--+--R--+--R--+-- Y Where each R is 1 Ohm. You're finding the resistance between the points A and B. We want to find the resistance between points A and B. Let's look at a simplification and find the resistance between points B and Y. You have two Rs in series and then each of these pairs are in parallel: 1/(1/(R+R) + 1/(R+R)) = 1/(1/2 + 1/2) = 1.
Care to guess what the resistance between A and B is?
As one of those types of engineers, specifically an electrical engineer, I was not happy to see *nix go. At that time, the programmable logic device and tool vendors saw the migration away from $20,000 Sun boxes. As a result, they moved to Windows. Now, however, many of the EDA tools are available for Linux (generally, supported only for RedHat) since engineers, like myself, have been constantly requesting Linux versions. Windows is still the primary platform, but Linux is now viable platform for programmable logic development.
Across every industry, real innovation is rare. You have a small handful of innovative ideas that get developed and evolve until they become common place but indispensable. There is nothing wrong with this process. It is rare to be able to go looking for real innovation and find it.
I think the thing to keep in mind in today's difficult job market is companies are looking for people who can hit the ground running. Unfortunately, this negatively affects people like me who have relatively broad experience, but not tremendous depth in any one area.
I find cover letters to be of dubious value. They are not always useless, but I don't think every electronic resume submission requires a cover letter.
Reinventing the Printed Circuit Board
on
Paper Mounted CPUs
·
· Score: 5, Interesting
It seems like the only possible innovation here is in the conductive inks. Effectively, they using a paper substrate rather than FR4 (or other PCB material) and the conductive "ink" rather than copper to make connections. The ability to make a very thin chip and embedded it into a thin form factor is not new.
The more interesting thing is the non-traditional markets that are being explored. They're not trying to do another smartcard rehash. (although they appear to talk about smartcard-lke devices on their web site)
You could bring the BOM of this project down by chucking the FPGA and using a microcontroller. The FPGA and its RAM and ROM are probably a large percentage of the total cost (the Xilinx Spartan II would cost around $15 with the ROM and SRAM chiping in a couple dollars). As a fun project that might allow you to learn something new, using the FPGA was interesting. However, you can find a microcontroller, potentially with integrated 10Mb Ethernet, that can do the job. You could also, potentially, do away with the external DAC by using a microcontroller with intergated DAC capability (e.g. Cypress Micro.
This project was meant as a fun learning exercise. Analyzing the BOM in terms of a production-quantity retail product is unfair.
For a more detailed treament of the topic, take a look at David Patterson's and John Hennessy's _Computer Organization & Design_. It is an excellent text book on the topic.
I am curious about the potential to remove useful parts off of the boards for resale to schools, hobbyists, or companies specializing in discontinue parts. The problem is the cost to remove the parts versus the pirce you could get for them. For example, it may cost US $1 in labor to salvage a 22V10, but why bother paying $1+ for a used part when new devices cost the same amount or less? Perhaps I have answered my own question.
I did misunderstood the point of your statement on individuals selecting what to ban. I don't think banning books is an answer. I would reword my original post to use "control access" rather than "block." I agree with another reply to my original posting that suggested the use of an ID to circumvent the software just as you might have to show ID to buy alcohol. This is better than not having the potential information from those sites available while still allowing the parents to decide what their kids can view.
I also agree with your second point--something like Penthouse might have a legitimate use. I would also say that there are many other sources that are equally valid for the same research (Vogue, Cosmo, etc.) that wouldn't be nearly as inflammatory. An "adults only" section would be fine, but it should be transparent. When a child goes toa library, I don't want them to think about what they're not allowed to see. Instead, they should be thinking about all the cool stuff they can view.
The mission of the LOC is a storehouse of published material. However, I disagree that the mission of local libraries is simply a storage facility or some uber portal of data. A local public library's mission, in my opinion, is a place to nuture education. The data they stock is a means to an end.
I'm not a good person on which to use The Bible Example (TM). I agree. Take all religious tomes to of a public library. There are better places to study religion. And, I think the sex and violence cited in the Bible pales in comparison to what can be seen on public television stations. Since the rules for obscenity center around what the local community finds objectionable, I don't think the Bible would rise to that level. The Bible does not give detailed descriptions of those acts like Penthouse Letters does. To say that person A had relations with person B who was person's A sister presents "mature sexual themes" but it is not an example of sex.
The implementation is awful, but the intent is acceptable. Why can't you go to a library and checkout/read Penthouse? Because Penthouse does not fit in with the mission of a library. The protecting our kids thing is great politics, but little more. I don't buy it and I don't like having others tell me what I should think is something my kids shouldn't see. However, I don't have a problem with a library using some form of control to block access to sites that lie outside of the mission of a public library.
No competent engineer is going to design something expecting to find fault later. However, assumptions are made during design. Component availability changes. Marketing requirements change. So, you push the corners, almost daring the design to brake. It's not because you're expecting failure, it's because you want to 1) Make sure it exceeds the (revised) set of requirements since you believe in putting out a quality product, and 2) You want to see just how far you can push it.
Software is an invaluable tool. Faster, better, more, in less time. You can't afford to do trial and error. When developing a product, the software TOOLS aid the engineer in design. Would you scoff at using a signal integrity tool to check those 533MHz front side bus traces, preferring to get down to the "resistors" when the board comes back? "Inventing" will always require some tinkering. That tinkering, however, is no longer limited to resistors, capacitors, inductors, and TTL logic parts. In additon to those parts, you've got FPGAs, microprocessors/microcontrollers, and software. Why are more tools/choice at your disposal a thing to be lamented?
The point of integrating the analog and digital circuits onto one chip is not just to shrink the size of the device. It'll make a more feature-rich device cheaper, more realiable, and should result in better battery life.
This is interesting for cell phones, but it has far more interesting possibilities in the general realm of analog and digital circuit integration.
If I were to guess at where there was the most potential for conversion from Windows to Linux, I'd guess low- to mid-end engineering apps (e.g. FPGA synthesis, place & route, simulation). It used to be that all engineering apps only an on UNIX (Solaris or HPUX). Then, these apps migrated to Windows. However, Windows was a terrible mess until recently for such apps. While Win2K has become a servicable platform for such apps, it's just "not the same" as the app under UNIX. Linux offers the same advantage experienced in the bygone days under Solaris/HPUX with the cost benefit of a free OS and inexpensive, powerful hardware.
I think something is being forgotten here. The reason SystemC came into existance is to provide a higher level of abstraction for system design. The ideal is to unify software and hardware design such that making trade-offs between the two is very easy. Should I implement this FFT in an FPGA or just keep it in C code and use an off-the-shelf DSP? How much does my throughput increase if I were to implement this accelerator in hardware?
The short term reality is that the current toolset will probably take SystemC code and generated VHDL or Verilog for synthesis. Why? Because RTL synthesis tools are mature and VHDL and Verilog are mature. You are much better off learning VHDL and/or Verilog and developing the RTL in one of those. Just as in any other area of engineering, having a good foundation of knowledge is always better then learning a specific language/skill. (I'll call this the principle of first principles) If you're trying to hide a fundamental lack of knowledge of programmable logic and logic gates in general, you'll dig a hole for yourself. While not direct logic equations, VHDL or Verilog will keep you closer to the hardware.
As for SystemC vs. JHDL, my current opinion would be to go with something based on C. Why? Because it is far more likely that you'd write C code for the low-level software required by your system than Java. Also, I think JHDL as currently defined is meant as a straight-up replacement of VHDL/Verilog. I, personally, don't see a compelling advantage to use JHDL over VHDL or Verilog for standard RTL flows.
It appears JHDL is being positioned as a better solution for describing reconfigurable systems. It may offer advantages for that niche. However, I'd agrue that any higher level language (e.g. SystemC) would offer an advantage given a good JHDL/SystemC synthesis tool that understood reconfigurable devices. The synthesis tool should be able to implement reconfigurable logic based on your higher level description.
Here, here.... It is VERY easy to write syntactically correct, but difficult to synthesize HDL code. The synthesis tool you'll be using is going to try to infer the logic it believes you're describing. Keep it simple. Write synthesis-friendly HDL code. Make sure you understand blocking vs. non-blocking statements (it'll haunt you during simulations). Always keep in mind that this high level description is going to be translated into logic gates. In your design flow, logic synthesis should not be the longest time sink (except for trivial designs).
An extremely important thing to remember about all programmable logic devices is that a tremendous amount of the die of a programmable logic device is wasted compared to an equivalent ASIC. Programmables require massic chip real estate for routing of signals. The routing structure is, arguably, the most important aspect of the device. You can put in all the whiz-bang specialized circuits you want, but you have to be able to use them (and, use more than one of them if they're tiled throughout the device). Routing is what enables that.
Also, the logic primitives in a programmable (e.g. a slice in a Xilxin Virtex FPGA) can run extremely fast. It is not the limiting factor in getting speed from an FPGA. The much bigger issue is routing.
In addition to the actual logic and routing, there's configuration bits (the SRAM/FLASH/antifuse bit that are used to actually cause the device to implement the logic you want) and the support logic to program the configuration bits. There are millions of configuration bits on larger FPGAs. And don't forget the fact that the IO cells in most FPGAs support multiple I/O standards and usually contain a flip-flop and a small amount of miscellaneous stuff (e.g. a couple muxes for the output enable and clock select).
On the software side, generating logic equations is well known. The issue is in taking advantage of the specific architecture of the targeted device and all it's special features. And the other issue is finding the optimal routing between the logic resources and memories you've used. Both of these issues have been and continue to be researched.
Slashdot Mirror
One other post mentioned that they also believe the key displays are 32X32. My 128X128 was a number pulled from the nether regions. Although, as others have also pointed out, I completely neglected color depth. So, it probably washes out anyway.
If that is a feature, I agree with you. And, with the quicky estimate I did, I believe it since my back-of-the-envelope calculation assumed 10fps.
That's a good point. Let's say they want 10 frames per second on each key and there are about 100 keys (rounding to make the calculation a little easier). If the resolution of each display is 128 pixels X 128 pixels, that's 16,384 pixels per display * 100 displays * 10 fps. That's 16,384,000 pixels that need to be touched each seconds. 16.384MHz isn't that fast. You could easily take a low cost FPGA (Xilinx Spartan/Altera Cyclone) and implement logic running four times that speed. So, I guess I'm back to believing it's possible.
I'd expect that to be unlikely only because I'd expect the refreah rate for the key displays to be very low. In order to get the hardware cost down, I expect there will be a lot of sharing of the logic used to update the displays. As a result, it could take on the order of seconds to update the display of a given key.
This is perfectly acceptable for the main function of a keyboard where waiting a couple seconds to load a new key layout isn't big deal (especially since the app won't load instantly anyway).
I don't get why people care that much about the team and player names. Dump the money required to license that garbage and diehard fans will do it anyway.
Is not gameplay the thing? That's where the real problem is. "Gary," the avid Madden fan mentioned in Greg Costikyan's blog, is absolutely correct--there's very little difference from year-to-year in the actual gameplay. I'm an NCAA Football fan. I did not buy the 2005 edition because the additions in the 2005 edition weren't that big of a deal. I might pick it up when there's a used copy for $20, but I feel no urgency.
I'll have a ton of fun with randomly generated player names and great gameplay. A static game with graphical facelifts from time-to-time and NFL player names will beg me to spend my money elsewhere.
While I can do without the condescending tone (I know that some current will flow even if the resistance is "large." It becomes a resistive divider. Even if you have 1 Ohm and 1 Megaohm, the 1 Megaohm path will carry a small amount of current.), I think I now understand your point.
... + 1/(n/2)]
... + 2/n]
The contention, then, is that since all paths start and end at the same points, all of them are in parallel with each other.
The first observation is to say that you have symmetry in this problem. You can find a path that goes up and the right that's 4 Ohms and a path that goes down and to the right that's 4 Ohms. Those two 4 Ohm paths are in parallel with each other and have an equivalent resistance of 2 Ohms. You can continue to do that for 5 Ohms, 6 Ohms, etc. And, since the pairs of parallel paths are the same value, the effect is to halve the resistance. So, you have 4/2=2, 5/2=2.5, 6/2=3, etc.
The next observation is that these paths are still in paralle with each other. This results in the equivalent resistance of 2\\5/2\\3\\7/2 etc. where I'm using \\ to mean "in parallel with." I'm going to assume you can find paths down to the base resistance of 1 Ohm. (Can we find a path with 1/2 Ohm resistance?) The 1 Ohm paths yield an equivalent resistance of 1/2 Ohms; Two 2 Ohnm paths yield an equivalent resistance of 1 Ohms, and so on. The pattern that emerges is:
1/2 \\ 2/2 \\ 3/2 \\ 4/2 \\ . . . \\ n/2
The equation for the total resistance is then
Rt = 1/[1/(1/2) + 1/(1/1) + 1/(3/2} +
= 1/[2 + 1 + 2/3 +
sum from i = 1 to infinity of 2/n.
We can break this up into the sum of two infinte sums:
even terms of original series: sum from 2 to infinity of 1 + 1/m
plus
odd terms: sum from 1 to infinity of 2+ 2/(2m+1)
I think the even-term sum converges to 2. I'm not sure what the odd-term sum converges to.
I think your arguement adds an additional assumption--that there are infinitely many knights moves taken. The original problem does not state that. The question stated, "what is the resistance between two nodes that are a knight's move away?" The question did not state "N knight's moves away" or the like.
I'll pose another question, what is the resistance across any single resistor in that lattice? According to you, the resistance is still an infinite series since you can take an infinite number of paths between those two points.
I think the assumption in my set up and solution is that this is the only "closed circuit." In other words, I'm assuming the resistance for all other paths is infinite (nothing else is connected), and, therefore, you'll measure the resistance only across the resistor network that I "drew." So, it's not the resistance from the starting point to the knight's move away point for all possible paths since the resistance of any other path is infinite.
.
Your assumptions are leading you down a path like that discussed here http://mathworld.wolfram.com/ResistorNetwork.html
I don't think you're drawing the diagram of the problem correctly. You're finding the resistance between two points defined by the knight's move ("two squares straight and one square to the side" http://chess.about.com/library/ble132kn.htm). As a result, the resistance is definately not infinite.
Each square of the infinite chess board has a resistor. Therefore, the squares involved in te knight's move look like this:
--+--R--+--R--+--R--+--B
| | | |
R R R R
| | | |
A--+--R--+--R--+--R--+--
Y
Where each R is 1 Ohm. You're finding the resistance between the points A and B. We want to find the resistance between points A and B. Let's look at a simplification and find the resistance between points B and Y. You have two Rs in series and then each of these pairs are in parallel: 1/(1/(R+R) + 1/(R+R)) = 1/(1/2 + 1/2) = 1.
Care to guess what the resistance between A and B is?
As one of those types of engineers, specifically an electrical engineer, I was not happy to see *nix go. At that time, the programmable logic device and tool vendors saw the migration away from $20,000 Sun boxes. As a result, they moved to Windows. Now, however, many of the EDA tools are available for Linux (generally, supported only for RedHat) since engineers, like myself, have been constantly requesting Linux versions. Windows is still the primary platform, but Linux is now viable platform for programmable logic development.
Across every industry, real innovation is rare. You have a small handful of innovative ideas that get developed and evolve until they become common place but indispensable. There is nothing wrong with this process. It is rare to be able to go looking for real innovation and find it.
I think the thing to keep in mind in today's difficult job market is companies are looking for people who can hit the ground running. Unfortunately, this negatively affects people like me who have relatively broad experience, but not tremendous depth in any one area.
I find cover letters to be of dubious value. They are not always useless, but I don't think every electronic resume submission requires a cover letter.
It seems like the only possible innovation here is in the conductive inks. Effectively, they using a paper substrate rather than FR4 (or other PCB material) and the conductive "ink" rather than copper to make connections. The ability to make a very thin chip and embedded it into a thin form factor is not new.
The more interesting thing is the non-traditional markets that are being explored. They're not trying to do another smartcard rehash. (although they appear to talk about smartcard-lke devices on their web site)
You could bring the BOM of this project down by chucking the FPGA and using a microcontroller. The FPGA and its RAM and ROM are probably a large percentage of the total cost (the Xilinx Spartan II would cost around $15 with the ROM and SRAM chiping in a couple dollars). As a fun project that might allow you to learn something new, using the FPGA was interesting. However, you can find a microcontroller, potentially with integrated 10Mb Ethernet, that can do the job. You could also, potentially, do away with the external DAC by using a microcontroller with intergated DAC capability (e.g. Cypress Micro. This project was meant as a fun learning exercise. Analyzing the BOM in terms of a production-quantity retail product is unfair.
For a more detailed treament of the topic, take a look at David Patterson's and John Hennessy's _Computer Organization & Design_. It is an excellent text book on the topic.
I am curious about the potential to remove useful parts off of the boards for resale to schools, hobbyists, or companies specializing in discontinue parts. The problem is the cost to remove the parts versus the pirce you could get for them. For example, it may cost US $1 in labor to salvage a 22V10, but why bother paying $1+ for a used part when new devices cost the same amount or less? Perhaps I have answered my own question.
I did misunderstood the point of your statement on individuals selecting what to ban. I don't think banning books is an answer. I would reword my original post to use "control access" rather than "block." I agree with another reply to my original posting that suggested the use of an ID to circumvent the software just as you might have to show ID to buy alcohol. This is better than not having the potential information from those sites available while still allowing the parents to decide what their kids can view.
I also agree with your second point--something like Penthouse might have a legitimate use. I would also say that there are many other sources that are equally valid for the same research (Vogue, Cosmo, etc.) that wouldn't be nearly as inflammatory. An "adults only" section would be fine, but it should be transparent. When a child goes toa library, I don't want them to think about what they're not allowed to see. Instead, they should be thinking about all the cool stuff they can view.
The mission of the LOC is a storehouse of published material. However, I disagree that the mission of local libraries is simply a storage facility or some uber portal of data. A local public library's mission, in my opinion, is a place to nuture education. The data they stock is a means to an end.
I'm not a good person on which to use The Bible Example (TM). I agree. Take all religious tomes to of a public library. There are better places to study religion. And, I think the sex and violence cited in the Bible pales in comparison to what can be seen on public television stations. Since the rules for obscenity center around what the local community finds objectionable, I don't think the Bible would rise to that level. The Bible does not give detailed descriptions of those acts like Penthouse Letters does. To say that person A had relations with person B who was person's A sister presents "mature sexual themes" but it is not an example of sex.
The implementation is awful, but the intent is acceptable. Why can't you go to a library and checkout/read Penthouse? Because Penthouse does not fit in with the mission of a library. The protecting our kids thing is great politics, but little more. I don't buy it and I don't like having others tell me what I should think is something my kids shouldn't see. However, I don't have a problem with a library using some form of control to block access to sites that lie outside of the mission of a public library.
No competent engineer is going to design something expecting to find fault later. However, assumptions are made during design. Component availability changes. Marketing requirements change. So, you push the corners, almost daring the design to brake. It's not because you're expecting failure, it's because you want to 1) Make sure it exceeds the (revised) set of requirements since you believe in putting out a quality product, and 2) You want to see just how far you can push it.
Software is an invaluable tool. Faster, better, more, in less time. You can't afford to do trial and error. When developing a product, the software TOOLS aid the engineer in design. Would you scoff at using a signal integrity tool to check those 533MHz front side bus traces, preferring to get down to the "resistors" when the board comes back? "Inventing" will always require some tinkering. That tinkering, however, is no longer limited to resistors, capacitors, inductors, and TTL logic parts. In additon to those parts, you've got FPGAs, microprocessors/microcontrollers, and software. Why are more tools/choice at your disposal a thing to be lamented?
The point of integrating the analog and digital circuits onto one chip is not just to shrink the size of the device. It'll make a more feature-rich device cheaper, more realiable, and should result in better battery life.
This is interesting for cell phones, but it has far more interesting possibilities in the general realm of analog and digital circuit integration.
If I were to guess at where there was the most potential for conversion from Windows to Linux, I'd guess low- to mid-end engineering apps (e.g. FPGA synthesis, place & route, simulation). It used to be that all engineering apps only an on UNIX (Solaris or HPUX). Then, these apps migrated to Windows. However, Windows was a terrible mess until recently for such apps. While Win2K has become a servicable platform for such apps, it's just "not the same" as the app under UNIX. Linux offers the same advantage experienced in the bygone days under Solaris/HPUX with the cost benefit of a free OS and inexpensive, powerful hardware.
I think something is being forgotten here. The reason SystemC came into existance is to provide a higher level of abstraction for system design. The ideal is to unify software and hardware design such that making trade-offs between the two is very easy. Should I implement this FFT in an FPGA or just keep it in C code and use an off-the-shelf DSP? How much does my throughput increase if I were to implement this accelerator in hardware?
The short term reality is that the current toolset will probably take SystemC code and generated VHDL or Verilog for synthesis. Why? Because RTL synthesis tools are mature and VHDL and Verilog are mature. You are much better off learning VHDL and/or Verilog and developing the RTL in one of those. Just as in any other area of engineering, having a good foundation of knowledge is always better then learning a specific language/skill. (I'll call this the principle of first principles) If you're trying to hide a fundamental lack of knowledge of programmable logic and logic gates in general, you'll dig a hole for yourself. While not direct logic equations, VHDL or Verilog will keep you closer to the hardware.
As for SystemC vs. JHDL, my current opinion would be to go with something based on C. Why? Because it is far more likely that you'd write C code for the low-level software required by your system than Java. Also, I think JHDL as currently defined is meant as a straight-up replacement of VHDL/Verilog. I, personally, don't see a compelling advantage to use JHDL over VHDL or Verilog for standard RTL flows.
It appears JHDL is being positioned as a better solution for describing reconfigurable systems. It may offer advantages for that niche. However, I'd agrue that any higher level language (e.g. SystemC) would offer an advantage given a good JHDL/SystemC synthesis tool that understood reconfigurable devices. The synthesis tool should be able to implement reconfigurable logic based on your higher level description.
Here, here.... It is VERY easy to write syntactically correct, but difficult to synthesize HDL code. The synthesis tool you'll be using is going to try to infer the logic it believes you're describing. Keep it simple. Write synthesis-friendly HDL code. Make sure you understand blocking vs. non-blocking statements (it'll haunt you during simulations). Always keep in mind that this high level description is going to be translated into logic gates. In your design flow, logic synthesis should not be the longest time sink (except for trivial designs).
An extremely important thing to remember about all programmable logic devices is that a tremendous amount of the die of a programmable logic device is wasted compared to an equivalent ASIC. Programmables require massic chip real estate for routing of signals. The routing structure is, arguably, the most important aspect of the device. You can put in all the whiz-bang specialized circuits you want, but you have to be able to use them (and, use more than one of them if they're tiled throughout the device). Routing is what enables that.
Also, the logic primitives in a programmable (e.g. a slice in a Xilxin Virtex FPGA) can run extremely fast. It is not the limiting factor in getting speed from an FPGA. The much bigger issue is routing.
In addition to the actual logic and routing, there's configuration bits (the SRAM/FLASH/antifuse bit that are used to actually cause the device to implement the logic you want) and the support logic to program the configuration bits. There are millions of configuration bits on larger FPGAs. And don't forget the fact that the IO cells in most FPGAs support multiple I/O standards and usually contain a flip-flop and a small amount of miscellaneous stuff (e.g. a couple muxes for the output enable and clock select).
On the software side, generating logic equations is well known. The issue is in taking advantage of the specific architecture of the targeted device and all it's special features. And the other issue is finding the optimal routing between the logic resources and memories you've used. Both of these issues have been and continue to be researched.